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Data  Model  and  Relational  Database  Design  for  the 
New  Jersey  Water-Transfer  Data  System  (NJWaTr) 

By  Steven  Tessler 


ABSTRACT 

The  New  Jersey  Water-Transfer  Data  System  (NJWaTr)  is  a  database  design  for  the  storage  and 
retrieval  of  water-use  data.  NJWaTr  can  manage  data  encompassing  many  facets  of  water  use,  including 
(1)  the  tracking  of  various  types  of  water-use  activities  (withdrawals,  returns,  transfers,  distributions,  con¬ 
sumptive-use,  wastewater  collection,  and  treatment);  (2)  the  storage  of  descriptions,  classifications  and 
locations  of  places  and  organizations  involved  in  water-use  activities;  (3)  the  storage  of  details  about 
measured  or  estimated  volumes  of  water  associated  with  water-use  activities;  and  (4)  the  storage  of  infor¬ 
mation  about  data  sources  and  water  resources  associated  with  water  use.  In  NJWaTr,  each  water  transfer 
occurs  unidirectionally  between  two  site  objects,  and  the  sites  and  conveyances  form  a  water  network.  The 
core  entities  in  the  NJWaTr  model  arc  site,  conveyance,  transfer/volume,  location,  and  owner.  Other 
important  entities  include  water  resource  (used  for  withdrawals  and  returns),  data  source,  permit,  and  alias. 
Multiple  water-exchange  estimates  based  on  different  methods  or  data  sources  can  be  stored  for  individual 
transfers.  Storage  of  user-defined  details  is  accommodated  for  several  of  the  main  entities.  Many  tables 
contain  classification  terms  to  facilitate  the  detailed  description  of  data  items  and  can  be  used  for  routine  or 
custom  data  summarization.  NJWaTr  accommodates  single-user  and  aggregate-user  water-use  data,  can  be 
used  for  large  or  small  water-network  projects,  and  is  available  as  a  stand-alone  Microsoft®  Access 
database.  Data  stored  in  the  NJWaTr  structure  can  be  retrieved  in  user-defined  combinations  to  serve  visu¬ 
alization  and  analytical  applications.  Users  can  customize  and  extend  the  database,  link  it  to  other  databases, 
or  implement  the  design  in  other  relational  database  applications. 


INTRODUCTION 

New  Jersey's  population  growth  and  development  continue  to  place  additional  demands  on  the  State's 
finite  water  resources.  Changing  demographics  and  economic  factors  can  increase,  decrease,  shift,  or  create 
new  demands  for  water.  Domestic  and  industrial  needs  typically  arc  balanced  with  agricultural,  recreational, 
wastewater  discharge,  and  ecological  uses;  however,  during  periods  of  drought,  sufficient  water  may  not  be 
available  to  meet  all  of  these  needs. 

To  better  manage  the  State's  water  resources,  the  New  Jersey  Department  of  Environmental  Protec¬ 
tion  (NJDEP)  has  designated  twenty  watershed  management  areas  for  which  detailed  management  plans 
will  be  developed.  Some  of  the  components  of  the  plans  include  water-quality  assessment,  land-use 
analysis,  habitat  evaluation,  and  water-budget  analysis.  The  ultimate  goal  of  this  process  is  to  develop  and 
implement  programs  that  will  maintain  or  improve  water  quality,  preserve  and  enhance  aquatic  and  land 
habitats,  and  meet  the  water  supply  needs  of  the  State. 

Multiple  NJDEP  programs  are  involved  with  the  regulation  of  the  State's  water  resources.  These 
programs  include  land  use,  water  quality,  water  supply,  and  wildlife.  A  common  issue  to  all  of  them  is  the 
amount  of  water  available  to  meet  the  competing  demands. 
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To  determine  the  amount  of  water  that  may  be  available  in  a  watershed,  one  must  understand  the 
water  dynamics  taking  place — the  amount  of  rainfall,  the  amount  and  fate  of  surface-  and  ground-water 
withdrawals,  the  amount  and  location  of  surface-  and  ground-water  discharges,  the  depletive  and  consump¬ 
tive  uses  of  water,  the  amount  and  location  of  water  transfers  between  watersheds,  and  the  amount  of  water 
that  is  naturally  leaving  the  watershed  as  streamflow  and  evapotranspiration.  An  accounting  or  water-budget 
model  is  needed  to  establish  how  much  ground-  and  surface-water  might  be  available  in  a  watershed  at 
different  times  and  under  different  use  scenarios. 

Problems  encountered  in  doing  such  analyses  arc  the  collection  of  data  and  the  availability  of  tools 
needed  to  store  and  manipulate  the  data.  Many  databases  are  in  use  by  the  NJDEP,  each  of  which  has  some 
of  the  information  needed  to  determine  a  water  budget;  none  contains  all  the  information  necessary  to  ac¬ 
complish  the  task. 

As  part  of  a  water-use  database  project  for  the  USGS  Districts  in  New  England,  the  New  England 
Water-Use  Data  System  (NEWUDS)  data  model  and  database  were  created  to  provide  a  tool  to  better 
organize,  store,  and  share  water-use  data  in  the  region  (Tessler,  2002).  To  support  water-budget  analyses  at 
the  watershed  scale  for  the  State  of  New  Jersey,  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr)  was 
developed,  in  cooperation  with  the  New  Jersey  Department  of  Environmental  Protection,  as  a  modification 
and  extension  of  NEWUDS.  The  core  model  of  both  systems  can  store  water-use  information  that  allows 
water  to  be  tracked  from  one  point  of  a  water-use  activity,  such  as  ground-  or  surface-water  withdrawal,  to 
a  second  point  of  water-use  activity,  such  as  a  drinking-water  service  area.  The  links  between  water-use 
activities  can  start  from  the  initial  withdrawal  from  the  resource  and  end  with  the  point  of  final  return.  The 
“link-node”  data  structure  present  in  both  NEWUDS  and  NJWaTr  has  been  recognized  as  the  recommended 
structure  for  storing  water-use  data  (Water  Science  and  Technology  Board,  2002,  p  1 19). 

NJWaTr  has  the  following  features. 

•  It  is  constructed  from  a  conveyance-based  data  model  rather  than  a  site -based  data  model,  thus 
promoting  and  encouraging  a  water-network  approach  to  water-transfer  and  water-use  data  storage  and 
investigation. 

•  It  accommodates  both  single-user  and  aggregate  water-use  data  in  a  single  data  model. 

•  It  is  implemented  as  a  stand-alone  and  portable  database  in  Microsoft®  Access  (MS  Access)  and,  there¬ 
fore,  is  accessible  to  a  large  number  of  potential  users.  The  design  can  be  recreated  in  any  other  rela¬ 
tional  database  management  system  with  some  modification. 

•  It  can  be  used  for  large  projects  (state  and  regional  studies)  and  small,  focused  projects  (watershed 
studies). 

•  It  is  fully  open  to  customization  and  extension. 

Although  the  order  of  topics  leads  from  conceptual  to  detailed  information,  some  readers  may  prefer 
to  read  the  document  in  a  different  order  or  to  identify  a  section  of  immediate  interest.  The  headings  for  the 
descriptive  sections  in  the  document  are  listed  below  with  a  brief  summary  of  the  contents. 

•  Development  of  the  NJWaTr  Data  Model — a  list  of  requirements  that  the  database  structure  had  to  meet, 
the  modeling  process,  and  the  software  used. 
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•  NJWaTr  Design  Principles — conventions  used  in  diagrams  illustrating  tables,  fields,  and  relationships; 
normalization  goals;  key  structures;  rationale  for  extensive  use  of  domain  tables;  naming  standards;  and 
functional  table  types. 

•  NJWaTr  Data  Model — definition  and  description  of  the  core  logical  entities  and  relationships  that  serve 
as  the  conceptual  foundation  for  the  NJWaTr  data  model,  description  of  tables  and  relationships  that 
constitute  the  core  of  the  NJWaTr  database,  and  individual  descriptions  of  subject  areas  within  the 
design. 

•  Operational  Issues  and  Procedures — items  related  to  working  with  data  within  NJWaTr,  including 
indexes,  table  loading  order,  supplied  maintenance  and  update  queries,  and  use  of  standardized  views 
as  templates  for  generalized  or  custom  data  extraction  and  exploration  activities. 

•  Customizing  and  Extending  the  Data  Architecture —  methods  recommended  for  adding  or  linking  new 
data  fields  or  tables  to  NJWaTr  without  compromising  the  database  structure. 

•  Summary — a  brief  summary  of  NJWaTr  and  some  advantages  of  using  the  database. 

•  References  Cited — a  list  of  references  cited  in  the  document. 

•  Appendixes — Appendix  1  contains  the  NJWaTr  Data  Dictionary,  which  lists  and  describes  each  table 
and  field  along  with  its  main  properties.  Appendix  2  contains  Domain  Table  Listings  that  show  the  clas¬ 
sification  and  descriptive  terms  used  to  uniformly  define  data  records  within  NJWaTr.  The  differences 
between  the  NJWaTr  and  NEWUDS  data  models  are  summarized  in  Appendix  3. 

This  report  is  intended  for  readers  who  have  some  background  in  the  design  or  use  of  relational  da¬ 
tabases.  Readers  who  arc  unfamiliar  with  data  models  or  relational  database  design  concepts  are  referred  to 
the  numerous  books  available  on  those  subjects  (for  example,  Fleming  and  von  Halle,  1989;  Hernandez, 
1997;  Roman,  1999)  or  to  the  Federal  data  modeling  standard  document  FIPS  184  (National  Institute  of 
Standards  and  Technology,  1993). 

Throughout  the  remainder  of  this  document,  logical  entities  arc  denoted  by  capitalization  (for 
example.  Site  and  Owner);  table  names,  field  names,  and  name  parts  arc  shown  in  italics  (for  example,  the 
table  tblSite ,  the  field  SiteTypeCategory,  and  the  suffix  _ID)\  example  data  values  for  fields  arc  shown 
within  quotes  (for  example,  SiteTypeCategory  =  “treatment”);  and  query  names  arc  shown  in  boldface  (for 
example ,  qrm V olumeUnitConversionF actor) . 


Purpose  and  Scope 

The  purpose  of  this  document  is  to  describe  the  NJWaTr  data  model  and  its  physical  implementation 
as  an  MS  Access  database.  Database  entities  and  relationships  along  with  their  components  are  shown  in 
illustrations.  Table  loading  order  and  preassembled  views  arc  listed  in  tables.  The  entire  database  design 
is  diagrammatically  represented  on  a  plate. 

This  report  is  intended  to  meet  the  following  user  needs: 

•  to  get  an  introduction  to  the  NJWaTr  data  model; 

•  to  evaluate  the  NJWaTr  storage  structure  for  use; 
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•  to  customize  a  copy  of  NJWaTr; 

•  to  link  NJWaTr  to  other  databases  (such  as  geographic  information  systems,  well-  and  stream-gage  in¬ 
formation,  or  water-quality  information); 

•  to  build  software  applications  that  service  NJWaTr  for  data  entry,  data  analysis,  or  reporting;  and 

•  to  understand  the  differences  between  the  NJWaTr  and  NEWUDS  data  models. 

NJWaTr  is  not  an  analytical  application,  but  rather  a  design  for  the  efficient  storage,  accurate  retriev¬ 
al,  and  custom  manipulation  of  water-use  data.  Exploratory  and  analytical  applications  can  be  developed 
to  work  directly  with  the  data  in  a  NJWaTr  database. 
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DEVELOPMENT  OF  THE  NJWATR  DATA  MODEL 

The  creation  of  a  model  that  accurately  describes  the  structure  of  a  set  of  data  is  a  precursor  to  any 
correctly  designed  database  (Fleming  and  von  Halle,  1989).  Data  modeling  is  the  formal  process  of 
analyzing  and  reducing  descriptions  of  information  into  separate  data  components,  and  establishing  the 
nature  and  direction  of  relationships  between  those  components,  thereby  building  a  structure  for  the  data 
that  automatically  enforces  the  rules  needed  to  maintain  data  integrity.  A  logical  data  model  integrates 
change  as  part  of  data  management  by  providing  a  generic  structure  that  permits  later  extensions  without 
affecting  the  validity  of  data  already  in  the  database.  A  data  model  also  is  used  to  create  and  maintain  doc¬ 
umentation  of  the  elements  that  comprise  the  database  and,  thus,  provides  a  common  language  and  reference 
for  all  users.  In  addition,  a  data  model  is  used  as  a  template  for  implementation  of  a  physical  database  design 
and  provides  a  structure  for  data  entered  into  the  database  to  meet  a  predetermined  level  of  detail  and  orga¬ 
nization. 


NJWaTr  Requirements 

A  set  of  data  and  user  requirements  is  used  to  clarify  the  use  of,  and  information  contained  in,  the 
database,  to  guide  the  development  of  the  database  structure,  and  to  serve  as  final  checkpoints  for  the  end 
product.  The  general  requirements  for  the  NJWaTr  database  design  arc 

•  Store  data  that  will  facilitate  summarization  of  withdrawals  and  water-use  activities  in  New  Jersey  (such 
as  in  Hoffman  and  Lieberman,  2000), 

•  Allow  for  the  storage  and  retrieval  of  information  on  single-user  and  aggregate  water  use, 

•  Store  classification  information  at  multiple  levels  on  the  uses  and  suppliers/users  of  water  to  allow  for 
flexibility  in  comparisons  and  aggregations, 
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•  Allow  data  to  be  summarized  in  different  spatial  contexts  by  storing  location  information  by  state, 
county,  municipality,  hydrologic  unit,  water  region  and  management  area,  critical  area  and  zone  for 
regulated  aquifers,  and  drought  region, 

•  Allow  area  (non-point)  locations  to  be  explicitly  partitioned  as  location-percentages  that  span  various 
geopolitical  and  hydrologic  boundaries  in  order  to  distribute  the  transfer  volumes  among  the  areas, 

•  Allow  for  the  storage  of  data  on  water  exchange  (volume  per  unit  time)  in  a  variety  of  measurement  and 
reporting  units  that  cover  a  range  of  transfer  time  scales  (for  example,  daily,  monthly,  or  annual  data) 
and  facilitate  the  conversion  of  the  data  to  common  units  of  measurement  so  that  data  arc  retrieved  in 
uniform  units, 

•  Allow  for  the  storage  of  alternative  estimates  of  individual  water  transfers  that  are  based  on  different 
determination  methods  or  data  sources, 

•  Allow  sites  and  owners  to  be  associated  with  and  identified  by  their  regulatory  permits, 

•  Allow  for  alternative  identification  and  naming  schemes  (aliases)  for  the  main  objects  listed  in  the 
database, 

•  Identify  sources  of  data  and  allow  contact  information  to  be  stored,  and 

•  Allow  optional,  user-defined  details  to  be  added  for  major  objects  in  the  database. 


The  Modeling  Process 

NJWaTr  is  a  modification  of  the  NEWUDS  design  (Tessler,  2002).  Development  of  the  NJWaTr 
database  began  with  a  review  of  the  functional  aspects,  strengths,  and  limitations  of  the  NEWUDS  data 
model.  This  was  followed  by  detailed  discussions  about  tracking  of  water  transfers  and  water  use  in  New 
Jersey.  A  conceptual  model  was  developed  to  meet  the  data-storage  goals  in  New  Jersey;  the  model  includes 
items  such  as  water  resources  (rivers,  canals,  ponds,  reservoirs,  and  aquifers),  water  uses,  water  purveyors, 
single  and  aggregate  water-users,  and  regulatory  identifiers  (permits  and  other  codes)  that  were  identified 
in  the  discussions.  The  major  data  objects  were  identified,  consolidated  where  appropriate,  and  represented 
in  the  conceptual  model  as  entities  with  defined  relationships.  The  existing  NEWUDS  data  model  then  was 
evaluated,  and  it  was  determined  that  NEWUDS  could  be  modified  to  meet  the  needs  of  a  relational  database 
for  New  Jersey.  Modifications  include  renaming,  redefining,  dropping,  and  adding  entities  and  attributes. 
When  a  general  concept  could  be  realized  in  more  than  one  data  structure,  the  alternatives  were  presented; 
the  implications  of  each  were  discussed,  and  the  contextually  accurate  structure  was  determined  and  incor¬ 
porated  into  the  model.  Exceptions  to  data  generalizations  and  required/optional  data  elements  were  identi¬ 
fied,  and  the  resulting  model  was  evaluated  and  revised.  This  process  continued  in  an  iterative  fashion  until 
all  the  information  elements  identified  in  the  NJWaTr  requirements  were  set  in  the  data  structure,  and  the 
factual  statements  represented  by  relationships  between  data  objects  were  accepted. 

Some  data  structures  that  did  not  exist  in  the  NEWUDS  design  were  modeled  in  NJWaTr  in  a  syn¬ 
tactically  correct  manner  but  had  to  be  tested  to  determine  whether  they  could  perform  their  intended 
functions  for  data  manipulation  and  information  retrieval.  Use  cases  were  developed  for  proof-of-concept 
testing  of  these  new  data  structures.  When  results  of  the  tests  confirmed  the  structures  were  valid  for  their 
purposes,  the  structures  were  discussed  and  incorporated  into  the  model. 
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Design  diagrams  and  listings  of  table/field  properties  (data  dictionaries)  were  used  during  discussions 
of  the  model  and  reviewed  between  meetings.  NJDEP  personnel  participated  in  the  design  phase  to  ensure 
that  the  database  contained  those  categorical  and  classification  terms  needed  to  store,  describe,  validate,  list, 
summarize,  and  aggregate  water-tracking  information.  A  guiding  principle  was  that  the  data  needed  to 
provide  answers  to  what,  where,  how,  and  when  questions  used  in  water-use  analysis  should  be  in  a  form 
that  is  familial-  to  the  user,  in  terms  that  are  well  defined  and  commonly  used. 


Modeling  Software 

The  NJWaTr  database  was  designed  using  the  data-modeling  tool  ERwin  version  3.5.2  (Computer 
Associates,  Inc).  Data-modeling  tools  facilitate  rapid  design  and  modification,  and  invisibly  handle  many 
details  of  the  data  structures  that  can  affect  the  quality  and  integrity  of  data.  ERwin  can  be  used  to  model 
and  generate  physical  databases  for  a  number  of  relational  database  management  systems.  For  MS  Access, 
ERwin  provided  editing  capabilities  for  application-specific  data  properties  through  a  physical  model  based 
on  the  logical  design.  After  the  NJWaTr  data  model  was  completed,  ERwin  was  used  to  create  the  physical 
implementation  of  the  database  in  MS  Access  by  providing  table  and  field  identities,  discrete  properties 
(field  type,  size,  and  default  values),  relationships,  and  all  table  and  field  constraints  that  ensure  the  integrity 
of  keys  and  data. 


NJWaTr  DESIGN  PRINCIPLES 

The  process  of  building  a  database  and  communicating  its  features  is  enhanced  by  establishing  certain 
rules  of  construction  and  standards  for  uniformity.  Design  principles  provide  standardized  rules  for  creating 
and  assembling  the  database  and  for  facilitating  communication  about  how  different  elements  of  the 
database  function  together.  This  section  describes  the  method  used  for  the  visualization  of  database  objects, 
the  goals  for  table  construction  and  establishing  formal  relationships,  the  rationale  for  extensive  use  of 
domain  tables,  and  the  naming  standards  applied  to  tables  and  fields. 


Entitv/Relationship  Diagramming  Conventions 

Entity/Relationship  (E/R)  diagrams  are  used  to  visualize  database  designs,  and  these  diagrams  are 
presented  throughout  this  report  to  help  describe  the  NJWaTr  structure.  Several  different  display  and 
notation  methods  are  commonly  used  for  E/R  diagrams,  and  all  allow  graphical/text  representation  of 
entities,  relationships,  and  attributes.  The  diagrams  in  this  document  use  the  Integration  Definition  for  In¬ 
formation  Modeling  (IDEF1X)  standard  as  defined  in  National  Institute  of  Standards  and  Technology 
(1993)  and  as  implemented  in  the  ERwin  modeling  software.  An  E/R  diagram  showing  the  complete  set  of 
relationships  between  Owners  and  Addresses  illustrates  several  diagramming  conventions  (fig.  1). 

In  the  E/R  diagram,  a  box  is  used  to  denote  an  entity,  which  equates  to  a  single  table  in  the  physical 
database.  The  table  name  appears  above  each  entity  box.  One  or  more  entity  attributes,  which  equate  to 
fields  in  the  physical  database,  are  listed  within  the  box.  Lines  connecting  entities  represent  the  defined  re¬ 
lationships.  Lines  signify  that  the  entities  share  a  key  field  and  can  be  linked  in  the  physical  database  through 
the  relationship. 

Each  attribute  within  a  table  is  shown  with  its  assigned  data  type  for  the  MS  Access  implementation 
of  NJWaTr.  A  primary  key  (PK)  is  the  field  or  group  of  fields  that  uniquely  identify  a  record  in  the  table. 
The  PK  for  each  entity  (composed  of  one  or  more  attributes)  is  listed  at  the  top  of  the  attribute  list  within 
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OwnerAddress 


OwnerType 

OwnerTypeJD:  Integer 

OwnerType:  Text(25) 
OwnerTypeMemo:  Memo 


Owner 


OwnerlD:  AutoNumber 

OwnerTypeJD:  Integer  (FK) 
ParentOwner  ID:  Long  Integer  (FK) 
OwnerName:  Text(200) 
OwnerContact:  Text(200) 
OwnerPhone:  Text(25) 
OwnerMemo:  Memo 


Owner  lD:  Long  Integer  (FK) 
AddressJD:  Long  Integer  (FK) 


Address 


AddressJD:  AutoNumber 

AddressTypeJD:  Integer  (FK) 
AddressLinel :  Text(50) 
AddressLine2:  Text(50) 

City:  Text(50) 

StateAbbrv:  Text(2) 

ZipCode:  Text(10) 
CountryAbbrv:  Text(3) 
AddressMemo:  Memo 


AddressType 

AddressTypeJD:  Integer 
AddressType:  Text(20) 


EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 
field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 
the  PK) 


STRONG  RELATIONSHIP 


WEAK  RELATIONSHIP 


PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

0 - Optional  FK  value  (weak,  diamond) 


CHILD  END  OF  RELATIONSHIP  (dot) 


PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 


(FK)  FOREIGN  KEY  FIELD 

(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


Figure  1.  Graphical  representation  of  entities,  attributes,  and  relationships  (E/R  diagram). 


the  entity  box  and  is  separated  from  the  non-PK  attributes  by  a  horizontal  line.  When  a  primary  key  from 
one  table  (the  parent)  is  used  in  another  table  (the  child)  to  create  a  defined  relationship,  the  field  is  called 
a  foreign  key  in  the  child  table  and  is  designated  by  FK  in  the  diagram. 

If  a  FK  field  also  is  paid  of  the  identifying  PK  in  the  child  table,  the  relationship  is  said  to  be  strong, 
and  the  relationship  line  is  solid  in  the  diagram  (fig.  1).  If  the  FK  field  is  a  non-PK  (descriptive)  attribute  of 
the  child  table,  the  relationship  is  said  to  be  weak,  and  the  line  is  dashed.  Both  strong  and  weak  relationships 
arc  illustrated  in  figure  1.  To  facilitate  visualization  of  table  dependencies,  a  table  that  is  dependent  upon 
another  through  a  strong  relationship  (a  FK  field  is  part  of  the  PK)  is  shown  with  rounded  corners,  whereas 
tables  that  do  not  have  FK  dependencies  in  their  PK  (independent  tables)  are  shown  with  squared  corners. 
Strong  relationships  pair  Owners  with  Addresses  in  the  table  OwnerAddress  in  figure  1  (the  incoming  FK 
fields  also  arc  PK  fields  in  the  child  table).  Weak  relationships  arc  represented  where  the  OwnerType  and 
AddressType  tables  provide  descriptive,  non-PK  attributes  to  the  tables  Owner  and  Address,  respectively. 

Each  relationship  line  has  a  direction  and  a  cardinality.  The  direction  is  indicated  by  the  presence  of 
symbols  at  the  parent  and  child  ends  of  the  relationship  line.  The  parent  entity  in  the  relationship  is  repre¬ 
sented  by  no  marking  on  the  relationship  line  or  a  hollow  diamond.  The  child  entity  in  the  relationship  is 
shown  by  a  solid  circle.  Direction  symbols  in  an  E/R  diagram  make  it  easier  to  visualize  the  flow  of  infor¬ 
mation  in  a  data  structure  and  are  especially  useful  for  identifying  parent/child  entities  in  a  PK/FK  relation¬ 
ship  in  which  one  table  provides  attributes  to  another. 

Cardinality  describes  how  each  record  in  one  entity  relates  to  a  count  of  records  in  another  entity,  and 
cardinality  is  denoted  on  diagrams  by  the  kind  of  symbols  on  the  ends  of  relationship  lines.  There  are  many 
possible  relationship  cardinality  variants.  In  a  one-to-one  (1:1)  relationship,  each  record  in  the  parent  entity 
has  exactly  one  match  in  the  child  entity.  In  a  one-to-many  (1  :n)  relationship,  each  record  in  the  parent  entity 
has  one  or  more  matching  records  in  the  child  entity.  In  the  NJWaTr  model,  all  but  two  of  the  relationships 
arc  one-to-zero-one-or-more  (l:0,n).  These  relationships  arc  indicated  by  a  solid  or  dashed  line  with  no 
symbol  on  the  parent  end  and  a  solid  circle  on  the  child-end.  These  relationships,  which  arc  illustrated  in 
figure  1,  arc  used  when  each  parent  can  have  zero,  one,  or  more  children,  but  each  child  must  have  a  parent 
(the  FK  cannot  be  unassigned  or  Null).  Thus,  each  OwnerType  (for  example,  “Municipality”)  can  serve 
zero,  one,  or  more  than  one  Owner,  and  each  Owner  must  have  an  assigned  OwnerType.  The  zero  paid  of 
the  relationship  cardinality  allows  an  OwnerType  record  to  exist  in  the  domain  without  actually  being  used 
by  an  Owner  until  needed  and  is  very  useful  for  filling  a  table  with  a  list  of  all  permissible  values  before 
other  data  arc  entered  into  a  database. 

The  other  cardinality  in  NJWaTr  is  shown  in  figure  1  as  the  self-join  for  Owner.  Each  Owner  record 
can  point  to  another  Owner  as  its  parent  by  storing  the  parent’s  Owner _ID  in  the  ParentOwner_ID  field. 
The  hollow  diamond  on  the  parent-end  of  the  self-join  relationship  line  means  that  the  relationship  is 
optional  (FK  may  be  Null);  that  is,  an  Owner  need  not  have  a  designated  Parent  Owner. 


Normalization 

Normalization  refers  to  the  process  of  structuring  a  database  to  avoid  data  redundancy  and  to  reduce 
complex  data  elements  to  their  component  parts  as  separate  tables  and  relationships  (Fleming  and  von  Halle, 
1989,  p.  179).  The  NJWaTr  model  is  structured  to  approximately  third  normal  form.  This  means  that  each 
table  stores  information  dependent  upon  a  single  key;  each  datum  or  descriptive  element  is  recorded  in  only 
one  location;  and  keys  to  those  data  are  carefully  dispersed  among  other  tables  as  surrogates  for  data  in  the 
parent  table.  Because  a  normalized  design  often  appeal's  to  be  rather  complex  and  cumbersome  to  manipu¬ 
late,  queries  are  constructed  that  aggregate  data  from  related  tables  in  a  denormalized  table  view.  This  fa- 


cilitates  data  review,  manipulation,  and  reporting,  while  the  actual  data  structure  is  hidden  from  the  user. 
(The  construction  of  denormalized  views  is  discussed  in  the  section,  “Construction  and  Use  of  Views.”) 


Kevs  and  Relationships 

Each  table  in  the  database  is  designed  to  hold  a  specific,  defined,  and  delimited  set  of  data.  Each 
record  in  a  table  (a  row  or  the  particular'  collection  of  data  it  represents)  is  identified  by  a  unique  PK  value, 
a  number.  The  PK  and  its  value  in  one  table  (the  parent)  can  be  used  in  another  table  (the  child)  as  a  surrogate 
for  all  the  information  it  represents  in  a  specific  row  of  the  source  table.  In  the  relationship,  the  PK  from  the 
parent  table  is  called  a  foreign  key  in  the  child  table.  The  relationship  established  between  tables  through 
the  shared  PK/FK  fields  provides  a  pathway  for  the  data  to  be  combined  into  a  single  view  of  the  records 
from  both  tables.  With  many  tables  related  to  one  another  in  various  combinations,  the  relational  model 
provides  a  way  to  extract  data  from  any  two  or  more  tables  in  any  combination  desired,  if  an  unambiguous 
pathway  of  relationships  exists  between  them. 

The  MS  Access  database  engine  protects  PK  fields  in  two  ways:  (1)  fields  identified  as  the  PK  must 
have  a  value  whenever  new  rows  are  added  to  a  table,  and  (2)  MS  Access  prevents  the  PK  values  from  being 
duplicated  in  other  rows  of  the  table  (each  PK  value  is  unique  within  a  table).  Most  tables  in  NJWaTr  have 
a  single  field  that  serves  as  the  PK;  the  PK  value  itself  is  an  incrementally  assigned  integer  that  represents 
a  row  of  data  in  the  table.  Exceptions  are  the  association  tables,  described  farther  on,  where  a  single  PK  field 
is  not  practical  or  desirable.  Thus,  information-rich  keys  (fields  that  have  apparently  unique  values,  such  as 
a  code  name)  that  could  serve  to  identify  data  rows  are  not  allowed  to  be  PK  fields  but  are  relegated  instead 
to  attributes  identified  by  an  information-neutral  numeric  key.  The  possibility  that  an  information-rich  key 
value  could  be  reassigned  in  practice  and,  thus,  corrupt  associated  data  in  other  tables  was  reason  enough  to 
prohibit  their  use  as  PKs  in  the  NJWaTr  model. 

In  some  tables,  a  complex  key  consisting  of  two  or  more  fields  could  serve  as  the  PK  (for  example, 
the  combination  of  a  town  code  and  a  state  code);  however,  the  convention  used  in  NJWaTr  was  to  relate 
tables  by  providing  a  single  field  to  serve  as  a  surrogate  for  any  such  complex  PK  (association  tables  ex¬ 
cepted).  The  design  was  standardized  to  use  a  single  field  as  a  PK  even  when  other  information  fields,  alone 
or  in  combination,  would  serve  the  same  purpose.  For  NJWaTr,  storage  of  a  surrogate  PK  does  not  add  sig¬ 
nificantly  to  the  size  or  complexity  of  the  database,  and  the  surrogate  key  is  more  convenient  to  use  than 
multi-valued,  complex  keys  carried  through  relationships  between  tables.  (For  additional  information  about 
the  advantages  of  using  surrogate  keys,  see  Lonigro,  1997.)  For  added  protection  against  duplication  of 
identifying  information  in  non-PK  fields  within  tables,  an  alternate  unique  index  may  be  created  in  a  table. 
(See  the  description  of  NJWaTr  indexes  in  the  “Indexes”  section.) 

Relationships  between  tables  are  built  into  the  database.  The  relationship  properties,  once  defined, 
are  enforced  by  the  MS  Access  database  engine.  To  protect  the  integrity  of  the  keys  across  tables,  referential 
integrity  constraints  are  placed  on  the  keys  through  the  relationship.  All  relationships  in  NJWaTr  have  a  set 
of  common  settings  for  protection  of  the  keys  and  the  data  they  represent. 

•  All  tables  have  a  PK  consisting  of  one  or  more  fields;  each  record  in  each  table  is  identified  by  a  unique 
key  value. 

•  All  non-recursive  FK  fields  are  required  to  hold  a  value  for  each  record,  and  the  FKs  must  take  a  value 
from  the  collection  of  parent  PK  values. 

•  Changes  to  the  value  of  a  PK  are  cascaded  to  child  records;  all  occurrences  of  the  PK  value  in  the  related 
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FK  in  other  tables  are  updated  automatically. 

•  Record  deletion  is  restricted  if  the  PK  value  also  exists  as  a  FK  value  in  another  table.  MS  Access 
displays  a  warning  when  children  of  the  record  (holding  that  FK  value)  arc  in  other  tables  and  prevents 
related  records  from  becoming  oiphans. 

These  rules,  along  with  enforcement  of  the  uniqueness  of  PK  values,  provide  the  basic  protection 
needed  to  prevent  key  corruption  and  to  maintain  table  and  referential  integrity  throughout  the  database.  Re¬ 
lationship  rules  can  be  adjusted  later  as  needed  after  experience  is  gained  with  NJWaTr. 


Domain  Tables 

In  NJWaTr,  lists  are  used  extensively  for  classification  or  description  of  items  in  the  database.  Lists 
that  serve  the  main  data  tables  and  each  other  constitute  41  of  the  76  tables  in  NJWaTr  (54  percent).  These 
tables  arc  called  domain  tables  because  each  provides  specific  information  describing  a  particular'  subject 
domain.  In  practice,  domain  tables  contain  the  set  of  permissible  values  from  which  actual  values  are  taken. 
An  example  of  a  domain  table  is  tdsState,  in  which  each  record  is  for  an  individual  state,  and  the  fields 
provide  information  on  the  state  (for  example,  name,  postal  abbreviation,  and  code  number).  A  relationship 
with  a  domain  table  can,  therefore,  provide  many  different  pieces  of  information  through  the  single  value 
of  the  inherited  key  field.  Domain  tables  significantly  enhance  sorting  and  grouping  options  for  the  related 
data  by  providing  discrete  tables  in  which  such  actions  can  be  initiated;  they  also  facilitate  maintenance  and 
periodic  evaluation  of  acceptable  values  for  a  subject  domain. 

The  value  of  the  many  separate  domain  tables  needs  to  be  emphasized  because  it  is  possible  to  store 
domain  data  as  fields  in  the  tables  they  serve.  Normalization  rules  dictate  that  data  must  be  compartmental¬ 
ized  as  much  as  possible  to  prevent  redundancy,  which  is  achieved  in  NJWaTr  by  using  discrete  domain 
tables.  Domain  tables  provide  considerable  power  to  NJWaTr  because  they  can  be  extended  as  needed  by 
adding  to  the  list  and  by  adding  new  descriptor  fields  without  affecting  the  rest  of  the  database  design. 

In  addition  to  acting  as  lookup  tables,  domains  are  used  to  create  larger  domain  structures  in  NJWaTr 
through  clustering  and  nesting.  A  domain  cluster  consists  of  two  or  more  unrelated  domain  tables  joined 
together  in  a  base  table  to  establish  a  valid  combination  of  domain  values;  the  base  table  can  have  additional 
attributes  that  describe  the  properties  of  each  specific  combination.  Clusters  of  domain  tables  can  be  used 
to  assemble  complex  sets  of  descriptive  or  hierarchical  information  from  a  limited  set  of  choices  (individual 
domains),  and  the  result  is  carried  through  to  a  single  key  value.  A  domain  cluster  example  in  NJWaTr  is 
the  VolumeUnit  entity  (described  in  the  “Transfer/Volume  Subject  Area”  section)  where  two  domains  are 
combined  in  a  single  table  to  provide  any  desired  combination  of  decimal  and  quantity  terms  in  a  controlled 
fashion. 

Nesting  of  domains  is  implemented  in  NJWaTr  where  hierarchies  of  descriptive  terms  are  maintained 
as  separate  lists  with  enforced  parent-child  relationships.  For  example,  states,  counties  and  minor  civil 
divisions  (MCDs),  which  roughly  correspond  to  towns,  are  represented  as  nested  domain  tables  that  serve 
the  Location  entity  for  Sites.  In  an  application,  nesting  would  be  implemented  as  the  ability  to  look  up  a  state 
to  reveal  its  counties  and  the  counties’  MCDs,  or  to  look  up  an  MCD  to  reveal  its  parent  county  and  state. 
In  a  nested  domain  structure,  the  table  that  contains  the  smallest-scale  descriptive  term  (MCD  in  the 
example  above)  is  usually  the  one  that  is  linked  to  a  data  table.  This  allows  any  of  the  larger-scale  levels  to 
be  retrieved  through  the  nesting  relationships  to  describe  the  data  object  they  serve. 
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Naming  Standards 

Naming  standards  convey  important  information  about  an  item’s  identity,  contents,  or  both  with  little 
more  than  an  understanding  of  the  convention  used.  In  the  NJWaTr  database,  naming  standards  apply  to 
both  tables  and  fields. 


Table-  and  Field-Name  Construction 

The  four  general  name-construction  standards  arc  listed  here  with  explanations. 

1.  Names  are  constructed  using  whole  words  (with  a  few  exceptions)  to  provide  as  much  intuitive  meaning 
as  possible. 

2.  For  names  that  arc  composed  of  word  phrases,  the  first  letter  of  each  word  in  the  phrase  is  capitalized 
to  assist  in  reading  the  name. 

Examples  of  phrased  field  names  include  ConveyanceDetailLabel,  ConversionToMillion , 
Timelnterval ,  and  TrcmsferEffectiveDcite .  Names  that  do  not  consist  of  whole  words  arc  constructed  using 
a  commonly  accepted  acronym  or  abbreviation,  specifically  MCD  (Minor  Civil  Division  of  the  U.S.  Census 
Bureau),  HUC  (Hydrologic  Unit  Code),  NJ  (New  Jersey),  and  MG  (million  gallons,  the  common  unit  used 
for  a  water-transfer  volume).  The  only  other  exceptions  to  the  use  of  whole  words  in  names  arc  Abbrv  for 
Abbreviation,  Det  for  Determination,  and  Mgmnt  for  Management.  The  abbreviations  help  limit  the  size  of 
item  names  without  affecting  their  readability,  specifically  StateAbbrv,  Country  Abbrv ,  VolumeUnitAbbrv, 
LocationDel Method,  and  WaterMgmntArea. 

3.  Names  are  constructed  only  of  alphabetic  characters;  no  numerals,  punctuation,  or  other  special  char¬ 
acters  (such  as  spaces  or  dashes)  are  allowed,  except  for  the  underscore  in  singular  PK  fields  that  consist 
of  the  table  root  name  and  an  _ID  suffix. 

The  exception  here  is  an  important  rule  of  its  own:  the  PK  field  of  each  non-associative  table  is  iden¬ 
tified  by  the  table  root  name  and  a  suffix  of  _ID,  such  as  Location_ID  as  the  PK  field  of  the  tblLocation 
table.  This  standard  of  using  an  _/Z)  suffix  for  a  key  field  allows  distinction  between  key  and  non-key  (data) 
fields.  The  presence  of  _ID  keys  as  FK  fields  in  a  table  also  clearly  indicates  that  one  or  more  non-key  fields 
are  available  in  a  related  table  of  the  same  name. 

In  NJWaTr,  six  field  name  variants  represent  three  special  cases  for  the  _ID  rule.  The  first  case 
involves  recursion  within  a  table  where  a  field  has  an  JD  suffix  and  points  to  another  record  in  the  same 
table.  The  recursion  keys  in  NJWaTr  arc  PcirentOwner_ID  and  ParentSystem_lD .  Use  of  these  fields  allows 
a  nested  hierarchy  to  be  represented  by  holding  a  value  pointing  to  the  PK  of  another  record  in  the  same 
table  ( ParentOwner_ID  to  Owner_ID  and  ParentSystem_ID  to  System_ID).  The  leading  word  Parent  in  the 
field  name  identifies  these  recursion  keys.  Use  of  these  fields  is  optional  so  that  top-of-hierarchy  items  or 
items  without  a  designated  Parent  are  not  required  to  hold  a  value. 

In  the  second  case,  a  component  structure  is  defined  by  pairing  a  parent  record  with  one  or  more  child 
records  from  the  same  table.  This  is  represented  in  the  table  tadResourceStructure  where  a 
ParentResource_ID  and  a  ChildRe source _ID  are  paired,  each  pointing  to  different  Resource  records  in  the 
tblResource  table.  The  Resource  record  identified  through  the  ParentResource_lD  is  a  composite  of  more 
than  one  Resource,  and  the  ChUdResource_ID  values  associated  with  it  indicate  the  other  Resources  that 
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make  up  that  composite.  The  tadResourceStructure  table  will  be  discussed  in  the  section,  “Resource 
Subject  Area.” 


In  the  third  case,  two  fields  use  combined  name  forms,  SiteTypeFromID  and  SiteTypeToID.  These 
fields  point  to  a  key  field  in  a  domain  ( SiteType_ID )  but  lack  a  direct,  defined  relationship  between  the 
tables.  These  fields  are  used  as  data  rather  than  keys  (PK  or  FK).  Thus,  the  underscore  must  be  omitted. 
The  table  maintenance  function  of  those  semi-key  data  fields  is  discussed  in  the  section,  “Conveyance 
Action  Phrase  Updates.” 

4.  Fields  with  a  Yes/No  data  type  begin  with  the  word  “Is,”  those  with  a  DateTime  data  type  end  with  the 
word  “Date,”  and  those  with  a  Memo  data  type  end  with  the  word  “Memo.” 

Fields  with  a  Yes/No  (Boolean),  DateTime,  or  Memo  data  type  arc  unlikely  to  need  modification  in 
a  working  implementation  of  the  NJWaTr  database,  so  coding  the  data  type  into  the  name  provides  infor¬ 
mation  about  the  nature  of  the  field.  Coding  the  data  types  of  all  other  fields  with  a  suffix  or  prefix  was  not 
considered  practical  because  the  data  types  or  sizes  of  some  fields  may  need  to  be  changed  as  experience 
grows  with  use  of  the  database.  For  example,  a  Text  field  may  need  to  be  converted  to  a  Memo  field  if  the 
storage  required  by  the  field  exceeds  256  characters,  or  a  single  precision  number  may  need  to  be  converted 
to  double  precision  to  accommodate  unanticipated  but  valid  values  for  a  field. 

Seven  Yes/No  fields  are  present  in  NJWaTr:  IsPrimciryMCD ,  IsPrimary County,  IsPrimary State, 
IsPrimciryHUC ,  IsPrimaryResource,  IsDefaultVolume ,  and  IsNumericDetail.  They  arc  named  as  a  question 
phrase  to  emphasize  the  Yes/No  nature  of  the  value  they  hold  for  each  data  record. 

Eight  DateTime  fields  are  present  in  NJWaTr:  ExpectedFractionEffectiveDate,  ExpectedFraction- 
EndingDate,  ResourceDetailEJfectiveDate,  ResourceDetailEndingDate,  SiteDetailEJfectiveDate, 
SiteDetailEndingDate,  TransferEffectiveDate ,  and  TransferEndingDate.  Each  of  these  fields  is  used  to  set 
a  bounding  date  on  a  data  record. 

Thirty  Memo  fields  are  present  in  NJWaTr,  and  all  but  one  use  the  word  Memo  as  a  suffix.  Memo 
fields  arc  optional,  do  not  have  size  limitations,  and  arc  used  to  store  remarks  or  notes  about  a  record  in  a 
table.  The  one  Memo  field  that  does  not  use  the  Memo  word  suffix  is  SiteContact.  The  table  tblSite  contains 
a  SiteMemo  field  for  general  notes  about  a  Site  record,  whereas  the  SiteContact  field  stores  variable  amounts 
of  contact  information  for  a  Site  record  and  cannot  be  limited  to  the  256  characters  of  a  MS  Access  text  field. 


Table  Functional  Prefixes 

For  MS  Access  databases,  table  prefixes  in  wide  use  today  arc  either  tbl  or  tlkp,  where  the  latter  refers 
to  lookup  (domain)  tables  and  the  former  to  all  other  tables.  NJWaTr  contains  76  individual  tables,  and  more 
than  2  functional  table  types  are  recognized.  To  facilitate  rapid  identification  and  communication  of  the 
function  of  different  tables  in  the  database,  five  functionally  distinct  types  of  tables  are  defined  by  a  three- 
letter  prefix  applied  to  the  table  name  (fig.  2).  Table  names  are,  therefore,  distinguishable  from  field  names 
because  all  table  names  have  lower  case  prefixes,  and  fields  do  not.  In  addition,  each  of  the  five  table  types 
is  displayed  in  a  different  color  in  diagrams  of  the  database  structure,  imparting  significant  and  immediate 
understanding  of  the  functional  relationships  of  data  elements  and  relational  structures.  The  five  table  name 
prefixes  used  in  NJWaTr  and  their  definitions  are  provided  below. 
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Functional  table  prefix  Diagram  display  format 

tbl —  basic  data  table 

yellow  display  color, 
square  corners 


tds  —  domain,  static 

blue  display  color, 
square  corners 


tdx — domain,  user-extendable 

gray  display  color, 
square  corners 


tas — association,  simple  tasOwnerAddress 

white  display  color, 
rounded  corners 

tad —  association,  with  data 

green  display  color, 
rounded  corners 


tadLocationHUC 

Location  JD  (FK)'' 

HUCJD  (FK) 

HUCFraction 

IsPrimaryFlUC 


OwnerJD  (FK) 
Address JD  (FK) 


\ - y 


tdxStaff 

Staff  JD 

Stafflnitials 
StaffName 
Staff  Affiliation 
StaffMemo 


tdsState 

State  JD 

CountryAbbrv 

StateCode 

StateAbbrv 

StateName 

StateLatitude 

StateLongitude 


tbIConveyance 

ConveyanceJD 

ConveyanceTypeJD  (FK) 
ConveyanceActionJD  (FK) 
ConveyanceName 
ConveyanceMemo 


Figure  2.  Examples  of  tables  with  functional  prefixes  and  their  diagram  display 
formats. 
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tbl — basic  data  table;  for  example,  tblConveycuice.  Basic  data  tables  hold  primary  data  entered  into  the 
database  and  include  non-associative  core  entities.  Typically  these  tables  arc  the  focus  of  denormaliza¬ 
tion  in  the  creation  of  multi-table  views  (discussed  in  the  section,  “Construction  and  Use  of  Views”). 
The  tbl  tables  have  a  single  PK  field  ( _ID  suffix)  that  is  an  incrementally  assigned  integer  for  each  new 
record  (an  AutoN umber  field)  and  is  guaranteed  by  MS  Access  to  be  unique.  These  tables  always 
contain  one  or  more  fields  that  are  FKs  from  domain  tables,  and  thus  tbl  tables  inherit  classification 
and  descriptive  terms  as  extended  attributes.  The  _ID  keys  from  tbl  tables  are  dispersed  as  FK  fields 
among  other  tables  in  the  database.  The  10  tbl  tables  in  NJWaTr  (13  percent  of  the  tables)  are 
tblAddress,  tblAIias,  tblConveycuice,  tblLocation ,  tblOwner,  tblPermit,  tblResource,  tblSite, 
tblTransfer,  and  tblVolume.  These  tbl  tables  arc  shown  as  yellow  rectangles  in  the  figures  in  this  report. 


The  next  two  functional  table  types  deal  with  domains  and  have  a  prefix  beginning  with  the  letters  td. 
These  tables  arc  used  to  provide  list  information  for  selective  use  in  other  tables.  Domain  tables  also  arc 
sometimes  known  as  lookup  or  reference  tables,  and  other  naming  conventions  in  the  database  industry  may 
use  the  tlkp  prefix. 

tds — domain  table,  static;  for  example,  tdsStcite.  Static  domain  tables  hold  a  list  of  classification  or  descrip¬ 
tive  items  that  arc  used  by  other  tables.  The  list  of  items  is  considered  static  because  it  is  pre-populated 
and  expected  to  be  complete  (for  example,  the  tdsState  table  is  fully  populated  with  records  that 
describe  New  Jersey  and  neighboring  states).  The  tds  tables  have  a  single  PK  field  (_ID  suffix)  that  is 
an  integer;  to  prevent  inadvertent  additions  to  the  static  list,  the  key  value  must  be  manually  entered 
whenever  new  entries  arc  made.  Manual  key  entry  also  allows  the  creation  of  custom  unique  key  values 
for  use  with  the  choice  list  so  that  the  table  is  not  limited  to  automatically  generated  numbers  (for 
example,  to  add  a  “0”  key  value  as  a  default  selection  that  represents  an  unknown  condition).  The  tds 
tables  typically  serve  one  or  two  receiving  tables;  therefore,  _ID  keys  in  tds  tables  arc  found  in  other 
tables  as  a  FK.  The  26  tds  tables  in  NJWaTr  (34  percent  of  the  tables)  arc  tdsAddressType, 
tdsConveyanceAction,  tdsConveycinceActionCategory,  tdsConveycinceType,  tdsCounty, 
tdsCriticalArea,  tdsCriticalZone,  tds  Drought  Region ,  tdsHUC ,  tdsLocationScale,  tdsMCD, 
tdsOwnerType,  tdsPermitSeries ,  tdsResourceType,  tdsSiteType ,  tdsSiteTypeCategoiy, 
tdsSiteTypeSubcategory,  tdsState,  tdsTimelnterval,  tdsUseGroup,  tdsUseType, 
tdsVolumeUnitDecimal,  tdsVolumeUnitQuantity,  tdsWaterBodyType,  tdsWaterMgmntArea,  and 
tdsWaterRegion.  These  tds  tables  are  shown  as  blue  rectangles  in  the  figures  in  this  report. 

tdx — domain  table,  user-extendable;  for  example,  tdxStajf.  User-extendable  domain  tables  provide  a  list  that 
the  user  can  add  to  as  needed.  These  tables,  therefore,  differ  in  an  important  way  from  tds  tables.  The 
tdx  tables  are  considered  incomplete  at  the  outset,  and  cannot  be  populated  fully  before  the  database  is 
used.  For  example,  new  entries  will  be  made  to  the  tdxStajf  table  whenever  new  staff  members  need  to 
be  identified  in  the  database.  The  tdx  tables  have  a  single  PK  field  (_ID  suffix)  that  is  an  AutoN umber 
field  (incrementally  assigned  integer)  to  facilitate  additional  entries  without  regal'd  to  key  value  assign¬ 
ment.  Although  similar  in  construction  to  tbl  tables,  tdx  tables  provide  an  extendable  domain  list  that 
is  used  to  characterize  records  in  data  tables,  rather  than  to  hold  primary  data  for  the  database.  The  15 
tdx  tables  in  NJWaTr  (20  percent  of  the  tables)  are  tdxAliasLabel,  tdxConveyanceDetailLabel, 
tdxDataSource,  tdxLocationDetMethod,  tdxPermitLabel,  tdxResourceDetailLabel, 
tdxSiteDetailCategoiy,  tdxSiteDetailLabel,  tdxStajf,  tdxSystem,  tdxSystemType, 
tdxVolumeDetailLabel,  tdxVolumeMethod,  tdxVolumeMethodCategory,  and  tdxVolumeUnit.  These 
tdx  tables  are  shown  as  gray  rectangles  in  the  figures  in  this  report. 
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The  final  two  functional  table  types  are  associative  and  have  a  prefix  beginning  with  the  letters  ta. 
These  tables  differ  from  other  types  in  that  they  arc  dependent  on  at  least  one  other  table  by  having  all  or 
part  of  their  PK  consist  of  FK  fields;  therefore,  records  in  these  tables  cannot  exist  without  the  presence  of 
a  source  record  in  a  parent  table.  Association  tables  serve  the  functions  of  (1)  resolving  potential  many-to- 
many  relationships  between  two  or  more  tables,  (2)  describing  a  property  relating  to  a  specific  combination 
of  records  from  other  tables,  or  (3)  describing  a  property  of  a  parent  table  that  is  defined  or  constrained  in 
some  way  by  another  attribute,  such  as  a  time  interval.  These  tables  also  arc  termination  or  reflexive  points 
in  the  data  flow  within  a  relational  design  in  that  they  have  incoming  but  not  outgoing  relationships;  the  PKs 
of  these  tables  arc  not  passed  on  as  FKs  to  any  other  tables.  Association  tables  also  arc  sometimes  known 
as  junction  or  intersection  tables. 

tas — association  table,  simple;  for  example,  tasOwner Address.  Simple  association  tables  arc  used  to  resolve 
many-to-many  relationships  between  two  or  more  tables  and  arc  composed  only  of  FK  fields  that  all 
participate  in  the  PK;  that  is,  each  field  in  the  table  is  paid  of  the  PK  and  also  a  FK  that  points  to  a  record 
in  another  table.  For  example,  use  of  the  association  table  tcisOwnerAddress  allows  an  Owner  to  have 
more  than  one  Address,  and  a  single  Address  can  serve  more  than  one  Owner.  The  tas  association  table 
name  is  a  combination  of  the  two  or  more  parent  table  names  that  share  the  association.  (In  this  case, 
records  from  tables  tblOwner  and  tbl. Address  arc  paired  in  the  table  tasOwnerAddress.)  The  tas  tables 
have  a  complex  PK  composed  solely  of  the  FKs  from  each  table  involved  in  the  association  (in  this 
case,  Owner_ID  and  Address  J  Dp  no  other  fields  arc  present  in  tas  tables.  MS  Access  maintains  the 
integrity  of  the  association  by  allowing  each  combination  only  once,  thus  ensuring  the  primacy  of  the 
key.  The  PK  values  in  tas  association  tables  can  be  entered  directly  to  limit  a  list  to  valid  combinations 
or  can  be  assembled  as  needed  by  deliberately  pairing  records  from  the  parent  tables  in  the  desired  com¬ 
binations.  The  1 1  tas  tables  in  NJWaTr  (14  percent  of  the  tables)  are  tasConveyanceAlias, 
tasConveyanceOwner,  tasOwnerAddress,  tasOwnerPerm.it,  tasResourceAlias,  tasSite Address, 
tasSiteAlias,  tasSitePermit,  tasSiteTypeDetailLabel,  tasSystemSite,  and  tasWaterBodyDetailLabel. 
These  tas  tables  arc  shown  as  white  rectangles  with  rounded  edges  in  the  figures  in  this  report. 

tad — association  table,  with  data;  for  example,  tadLocationHUC.  As  used  here,  tad  association  tables  with 
data  represent  a  collection  of  functional  table  types  that  share  two  identifying  characteristics.  (1)  They 
arc  dependent  tables  with  at  least  one  field  in  the  PK  that  is  a  FK  from  another  table.  (2)  They  have  at 
least  one  field  that  is  not  paid  of  the  PK.  Some  tad  tables  also  may  contain  a  non-FK  field  in  the  PK, 
such  as  a  time  constraint.  The  tad  association  table  name  either  is  a  phrased  combination  of  the  two  or 
more  parent  tables  similar  to  tas  tables  (for  example,  tadLocationHUC )  or  is  a  phrase  that  begins  with 
the  root  name  of  the  main  table  being  served  plus  one  or  more  descriptor  terms  (for  example, 
tadResourceDetail).  The  14  tad  tables  in  NJWaTr  fall  into  four  groups. 

In  their  simplest  form,  tad  tables  arc  similar  to  tas  tables  in  that  they  pair  records  from  two  or  more 
tables  to  form  a  PK  that  consists  solely  of  FK  fields,  but  they  also  store  data  that  describe  some  property 
unique  to  the  association  itself  (that  is,  to  the  combination  of  values  that  form  the  PK).  For  example, 
tadLocationHUC  combines  a  Location_lD  with  a  HUC_ID  (identifying  a  specific  hydrologic  unit  or 
watershed)  to  form  its  PK;  like  tas  association  tables,  this  allows  individual  Locations  (for  example,  a 
county-level  aggregate  location)  to  be  associated  with  more  than  one  HUC  and  each  HUC  to  be  asso¬ 
ciated  with  more  than  one  Location.  Unlike  a  tas  table,  however,  the  tadLocationHUC  table  also  adds 
two  non-key  fields,  HUCFraction,  which  stores  the  fractional  paid  of  the  Location  represented  within 
the  paired  HUC,  and  IsPrimaryHUC,  which  defines  the  individual  pairing  of  key  values  that  represent 
the  HUC  that  should  be  always  be  retrieved  with  the  Location  whether  or  not  more  than  one  HUC  is 
associated.  Tables  with  this  structure  arc  tadConveyanceDetail,  tadLocationCounty, 
tadLocationHUC,  tadLocationMCD ,  tadLocationState,  tadSiteU seType ,  and  tadVolumeDetail. 
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A  second  form  of  tad  table  also  contains  FKs  from  two  or  more  tables  but  includes  a  non-FK  field  as 
part  of  the  primary  key  to  provide  an  important  constraint  on  the  association.  Three  tables  are  in  this 
group:  tadResourceDetail,  tadSiteConveyance,  and  tadSiteDetail.  In  the  tables  tadResourceDetail  and 
tadSiteDetail,  the  three-part  PK  consists  of  a  main  parent  entity  _ID,  a  domain  Label_ID,  and  an 
EffectiveDate  date/time  field.  Adding  the  temporal  field  to  the  PK  allows  a  main  parent  entity  record 
to  be  paired  with  the  same  Label  multiple  times  to  show  how  an  attribute  specific  to  the  association 
changes  over  time,  and  therefore,  a  history  of  values  can  be  maintained.  The  third  table  in  this  tad  group 
is  tadSiteConveyance  in  which  two  Sites  need  to  be  defined  as  the  endpoints  of  a  unidirectional  Con¬ 
veyance.  The  PK  consists  of  the  FK  field  Conveyance_ID  and  the  non-FK  field  FromOrTo  that  can 
hold  only  two  possible  values,  “From”  or  “To.”  Thus,  the  PK  ensures  that  each  Conveyance  can  have 
only  two  records  in  the  table  to  represent  the  separate  end  points  as  Conveyance_ID  +  “From”  and 
Conveyance_ID  +  “To.”  The  final  field  in  the  tadSiteConveyance  table  is  the  Site_ID,  which  is  a  FK 
field  but  does  not  participate  in  the  PK;  it  is  the  attribute  that  identifies  the  individual  Site  at  the  From 
or  To  end  of  a  Conveyance. 

A  third  form  of  tad  table  is  represented  by  the  three  tables  tadUseConsumedFraction, 
tadConveyanceExpectedFraction,  and  tadResourceStructure .  These  tables  receive  their  FK  field(s) 
from  only  one  parent  table  and  essentially  “hang”  additional,  conditional,  descriptive  attributes  off  the 
parent  table.  The  table  tadUseConsumedFraction  pairs  a  UseType_ID  with  a  Month  to  store  a  static 
numeric  value  applicable  to  a  particular  month  of  the  year  for  a  UseType.  The  table 
tadConveyanceExpectedFraction  uses  a  PK  that  combines  a  Conveyance _ID  with  an 
ExpectedFractionEffectiveDate  field  to  allow  multiple,  time-bounded  fraction  values  to  be  stored  for 
a  Conveyance.  The  table  tadResourceStructure  has  a  PK  that  consists  of  two  FKs, 
ParentResource_ID  and  Ch ildReso u rce_I I) .  both  of  which  represent  Resource_ID  selections  that 
define  the  parent  and  child  relationships  of  composite  water  Resources,  along  with  a  fractional  value 
unique  to  each  combination  of  parent/child. 

The  last  tad  table,  tadSiteResource,  is  critical  to  defining  the  relationship  between  those  Sites  involved 
in  withdrawals  or  returns  and  their  associated  Resources.  This  dependent  table  has  only  the  FK  field 
Site_IF>  as  the  PK  and  will  hold  only  records  for  Sites  that  interact  with  Resources.  In  addition  to  the 
single  PK  field,  non-PK  fields  in  this  table  are  the  FK  Resource_ID ,  an  integer  field  ConnectionCount, 
and  two  domain  FKs  Critic alArea_ID  and  CriticalZone_ID  characterizing  well  locations  in  regulated 
aquifers  (a  FK  value  for  “not  applicable”  is  assigned  to  Sites  where  those  domains  do  not  apply).  By 
keeping  Site_ID  as  the  sole  PK  field,  each  Site  record  is  constrained  to  be  associated  with  only  one 
Resource  record,  and  the  additional  properties  that  describe  the  Site-Resource  pairing  also  can  be 
stored.  Because  only  Sites  that  interact  directly  with  a  Resource  can  have  a  record  in  this  table,  the 
structure  is  sometimes  referred  to  as  a  subtype  (Fleming  and  von  Halle,  1989).  In  NJWaTr,  the 
tadSiteResource  table  functions  to  store  a  dependent  Site-Resource  association  along  with  properties 
specific  to  each  pairing,  so  it  is  included  with  the  other  tad  tables. 

To  summarize,  tad  tables  represent  a  collection  of  dependent  tables  that  contain  non-FK  fields.  They 
arc  used  to  resolve  potential  many-to-many  relationships  along  with  some  property  unique  to  the  asso¬ 
ciation  or  to  describe  a  value  for  records  from  one  or  a  combination  of  tables  that  is  constrained  in  some 
way.  Further  study  of  a  variety  of  data  models  should  help  refine  the  recognition  and  definition  of  the 
functional  table  types  represented  here  by  tad  tables,  but  for  now  they  arc  handled  as  a  composite  group 
with  a  single  prefix  and  diagram  color.  The  14  tad  tables  in  NJWaTr  (18  percent  of  the  tables)  are 
tadConveyanceDetail,  tadConveyanceExpectedFraction,  tadLocationCounty,  tadLocationHU C, 
tadLocationMCD,  tadLocationState,  tadResourceDetail,  tadResourceStructure,  tadSiteConveyance, 
tadSiteDetail,  tadSiteResource,  tadSiteUseType,  tadUseConsumedFraction,  and  tadVolumeDetail. 
These  tad  tables  arc  shown  as  green  rectangles  with  rounded  edges  in  the  figures  in  this  report. 
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Recognizing  and  understanding  the  naming  conventions  described  above  can  be  useful  in  exploring 
the  NJWaTr  database.  New  fields  or  accessory  tables  created  to  extend  the  functionality  of  the  database 
should  follow  the  naming  conventions  to  ensure  uniform  communication  about  the  identity  and  functional 
properties  of  the  new  items.  Refer  to  section  “Customizing  and  Extending  the  Data  Architecture”  for  more 
information  on  how  this  can  be  accomplished. 


NJWaTr  DATA  MODEL 

The  full  structure  of  the  NJWaTr  logical  model  and  physical  design  is  presented  in  this  section.  First, 
the  core  entities  and  their  relationships  arc  defined  and  described.  The  model  then  is  broken  into  subject 
areas  centered  on  specific  entities.  Detailed  explanations  arc  provided,  and  new  related  entities  arc  intro¬ 
duced  at  the  submodel  scale.  The  general  use  of  addresses,  data  sources,  permits,  aliases,  and  user-defined 
details  for  different  subject  areas  is  discussed  in  the  last  five  parts  of  this  section. 

NJWaTr  contains  76  tables,  95  defined  relationships,  and  311  fields.  The  complete  structure  is  shown 
in  plate  1.  Forty-one  of  the  76  tables  in  the  NJWaTr  database  arc  domain  tables  (54  percent),  25  are  asso¬ 
ciation  tables  (33  percent),  and  10  arc  basic  data  tables  (13  percent).  The  dominance  of  domains  in  the  dis¬ 
tribution  of  non-key  fields  in  tables  is  similar:  of  160  non- key  (data)  fields  in  the  database,  99  (62  percent) 
arc  in  the  domain  tables,  including  15  Memo  fields  for  notes  about  domain  entries.  The  extensive  use  of 
domain  tables  provides  flexible  classification  of  the  data  elements,  and  the  tables  serve  as  the  primary 
objects  for  grouping,  sorting,  filtering,  and  summarizing  information. 

Appendixes  1  and  2  provide  the  complete  NJWaTr  data  dictionary  and  lists  of  the  values  represented 
by  the  domain  tables,  respectively.  The  data  dictionary  provides  definitions  for  each  table  and  field  in  a 
tabular  format.  Readers  can  refer  to  those  pages  for  additional  details  not  given  below. 


Definition  of  the  NJWaTr  Core  Entities 

The  core  of  the  NJWaTr  data  model  can  be  illustrated  by  the  following  statements  and  conceptual 
diagrams.  More  details  for  each  entity  arc  given  farther  on  in  this  document. 

Each  object  that  can  be  named  as  a  source  or  target  of  water  movement  is  called  a  Site.  A  Site  can  be 
a  discrete  object  such  as  a  well,  water-treatment  plant,  or  commercial  business,  or  an  object  with  more  than 
one  component  represented  by  a  single  Site  name  (for  example,  a  purveyor  service  area).  Sites  arc  catego¬ 
rized  by  types  and  have  other  definable  characteristics.  Any  two  Sites  that  exchange  water  arc  joined  by  a 
unidirectional  Conveyance,  which  can  be  an  actual  pipe,  conduit,  or  aqueduct,  or  a  virtual  representation  of 
the  connection  between  the  Sites.  A  single  Site  can  serve  as  the  input  or  output  end  for  multiple  Convey¬ 
ances.  Together,  all  Sites  and  their  Conveyances  form  a  water  network.  This  is  equivalent  to  the  “link-node” 
data  structure  recommended  for  storing  water-use  data  (Water  Science  and  Technology  Board,  2002,  p  1 19). 

A  Transfer/Volume  is  a  record  of  a  single  water-movement  estimate  reported  from  or  calculated  for 
a  specific  Conveyance  between  two  Sites  over  a  specified  time  interval.  Each  Transfer/Volume  is  charac¬ 
terized  at  minimum  by  a  volume  value  for  the  water  exchange,  a  unit  of  measurement,  the  time  interval 
covered  by  the  estimate,  and  the  source  and  method  of  the  estimate.  The  full  history  of  Transfer/Volume 
values  can  be  stored  for  all  Conveyances  and  the  Sites  they  connect.  A  representation  of  estimated  daily 
Transfcr/V olume  values  for  the  Conveyance  between  a  well  and  a  treatment  plant,  as  measured  and  reported 
by  the  treatment  plant  operator,  is  shown  in  figure  3. 
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1  Jan  1997  0.22  Mgal 

2  Jan  1997  0.28  Mgal 

3  Jan  1997  0.33  Mgal 

4  Jan  1997  0.27  Mgal 


Distribution 
System  A 


J  V 


\ 

Distribution 
System  B 
_ ) 


Figure  3.  Representation  of  a  small  water  network  consisting  of  a  withdrawal  well, 
a  treatment  plant,  and  two  distribution  systems,  along  with  their  unidirectional 
conveyances  and  four  estimated  daily  transfer/volume  values  for  one  conveyance. 
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Two  additional  entities  complete  the  core  of  the  data  model.  The  spatial  Location  of  each  Site  is 
defined  by  a  scale  term  (point  or  specified  area)  and  latitude  and  longitude  coordinates  (actual  point  or  cen¬ 
troid);  realistically,  more  than  one  Site  can  share  the  same  Location.  Location  information  provides  a  spatial 
reference  and  visualization  potential  for  the  water  network.  Each  Location  also  links  to  a  hierarchy  of  other 
spatial  attributes  (town,  county,  state,  hydrologic  unit,  and  others).  A  spatial  representation  of  an  example 
water  network  is  shown  in  figure  4.  In  this  network  a  withdrawal  well  and  treatment  plant  share  a  single 
point  Location  (parts  of  a  single  facility),  and  two  town  distribution  systems  (each  an  additional  Site  in  the 
data  model)  are  located  at  town  centroid  positions.  The  reciprocal  exchange  of  water  between  the  two  dis¬ 
tribution  systems  is  indicated  by  two  unidirectional  Conveyances. 

An  Owner  controls  and  maintains  Sites  and  Conveyances  and  can  serve  as  the  source  of  the  Transfer 
data.  Each  Site  and  Conveyance,  therefore,  is  associated  with  an  Owner.  Owner  type  categories  include  a 
person,  an  organization,  or  a  municipal  or  government  agency.  Each  Owner  can  own  one  or  more  individual 
elements  and  can  be  paid  of  a  larger  parent  organization.  For  the  example  shown  in  figure  4,  the  well, 
treatment  plant,  and  distribution  system  A  might  be  owned  by  Town  A,  whereas  distribution  system  B  might 
be  owned  by  Town  B.  Additional  information  stored  for  each  Owner  includes  contact  and  address. 

In  summary,  pairs  of  Sites  are  joined  through  unidirectional  Conveyances,  on  which  are  recorded  in¬ 
dividual  water  Transfer/Volumes.  Locations  of  Sites  define  the  spatial  representation  of  the  water  network, 
and  information  is  stored  about  the  Owner  of  each  Site  and  Conveyance.  These  statements  describe  the  basic 
conceptual  core  of  the  NJWaTr  data  model. 


Core  Data  Model 

The  core  NJWaTr  E/R  diagram  (fig.  5)  is  an  extension  of  the  conceptual  model  described  previously. 
(Only  the  definitions  of  the  tables  are  shown  in  figure  5  because  the  details  will  be  presented  in  later  sec¬ 
tions.)  The  core  tables,  along  with  their  principal  attributes  and  relationships,  arc  described  in  the  following 
paragraphs. 

Each  object  that  can  be  named  or  identified  as  the  source  or  target  of  water  movement  in  the  water- 
use  network  is  called  a  Site.  Sites  can  be  as  small  as  an  individual  well  or  as  large  as  an  aggregate  of  users 
in  a  County,  if  that  is  the  only  scale  for  which  actual  water-use  data  arc  available.  Each  Site  is  uniquely  iden¬ 
tified  in  the  tblSite  table  by  a  Site_ID  value  and  described  by  a  Location  and  Owner  (or  owner  organization). 
A  Site  that  interacts  directly  with  a  water  resource  (withdrawals  or  returns)  is  paired  with  a  Resource 
through  an  association  table,  tadSiteResource. 

All  water  movements  arc  described  as  exchanges  between  individual  Site  pairs.  The  connections 
between  these  Site  pairs  for  water  exchange  arc  called  Conveyances,  and  each  Conveyance  is  uniquely  iden¬ 
tified  in  the  table  tblConveyance  by  a  Convey  mice _ID.  Conveyances  arc  modeled  as  strictly  unidirectional; 
therefore,  Sites  that  can  exchange  water  in  either  direction  will  have  two  Conveyances,  one  for  each  direc¬ 
tion.  This  is  necessary  to  ensure  that  all  water  movements  are  recorded  as  non-negative  values  and  to  have 
complete  control  over  defining  Sites  as  either  the  source  or  target  of  individual  water  Transfers. 

The  Site-Conveyance  relationship  is  strictly  a  2:1  relationship  (two  Sites  to  each  Conveyance),  and 
it  is  the  critical  element  in  defining  the  water-use  network.  Two  Sites  form  the  ends  of  each  Conveyance, 
one  at  the  input  (source)  end  and  the  other  at  the  output  (target)  end.  An  association  table, 
tadSiteConveyance ,  is  used  to  pair  the  two  Sites  to  a  single  Conveyance.  Each  Conveyance  will  have  exactly 
two  records  in  this  table,  one  for  each  Site  to  which  it  joins.  Only  one  From  (source)  Site  and  one  To  (target) 
Site  can  exist  for  each  Convey ance_ID.  The  required  non-PK  attribute  of  tadSiteConveyance  is  the  Site_ID 
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Town  A 


CROSSJUNCTION 


wms 


LOSTBRIDGE 


RIVERTOWN 


Town  B 

Distribution  System 


TRACKSIDEVILLE 


Well  and 
Treatment  Plant 


Figure  4.  Spatial  representation  of  sites  and  unidirectional  conveyances  of  a  small  water  network. 
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tbISite 


Site  involved  in  water-use  activities; 
includes  wells,  intakes  and  outfalls, 
distribution  and  treatment  facilities, 
collection  systems,  industrial, 
commercial  and  domestic  users,  and 
aggregate-use  entities 


tadSiteConveyance 

(  ~  ‘  \ 

L  •  Association  of  a  Site  with  one  end  of  a 

-•  Conveyance  (From  or  To) 


tbIConveyance 


Conveyance  that  serves  as  the 

water-carrying  connection  between  two 

Sites  (unidirectional);  includes  pipes, 

canals  and  conduits,  trucking,  and 

virtual  linkages 

tbITransfer 

• 

Record  of  a  water  Transfer  on  a 

Conveyance  between  two  Sites  for  a 

specified  Time  Interval 

tbIVolume 

• 

Volume  (quantity  of  water)  recorded  for 

a  Transfer  based  on  a  specific 

Determination  Method  and  Unit 

tadSiteResource 


Association  of  a  Site  with  a  water 
Resource 


tbILocation 

Location  information  for  a  Site, 
including  scale,  coordinates,  and 
association  with  geopolitical  and 
hydrologic  areas 


tbIResource 

Water  Resource  involved  in  water-use 
activities  (withdrawls,  transfers,  and 
returns);  includes  aquifers,  springs, 
streams  and  rivers,  lakes  and 
reservoirs,  estuaries  and  embayments, 
and  the  ocean 


EXPLANATION 

Functional  Table  Types 


tbIOwner 

Owner  organization  or  entity  that  owns, 
controls  or  monitors  a  Site,  Conveyance 
or  water  Resource,  or  is  the  parent 
organization  for  a  Data  Source 

7 


tasConveyanceOwner 


r 

Association  of  a  Conveyance  with  an 
Owner 

v  J 


J 

1 


tbl 


tdx 


tad 


BASIC  DATA  TABLE;  tbl  prefix;  yellow 

DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 

ASSOCIATION,  SIMPLE;  tas  prefix;  white 

ASSOCIATION,  WITH  DATA;  tad  prefix;  green 


Table  and  Relationship  Symbols 


tdxDataSource  % 

User-Extendable  List  of  the  Sources  of 
Data  being  stored 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

-  field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 
_  the  PK) 

-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

' -  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

0 -  Optional  FK  value  (weak,  diamond) 


CHILD  END  OF  RELATIONSHIP  (dot) 


Figure  5.  Core  tables  and  relationships  in  NJWaTr. 


field,  which  identifies  the  Site  at  the  From  or  To  Conveyance  end.  The  association  table  allows  multiple 
Conveyances  associated  with  individual  Sites  to  be  identified  quickly,  and  the  FromOrTo  field  assists  in 
describing  each  Conveyance  as  an  input  or  output  connection  to  a  Site.  A  hypothetical  example  of  records 
in  the  tadSiteConveyance  table  is  shown  in  figure  6,  where  the  highlighted  Conveyance  identified  as 
Conveyance _ID  =  “28”  is  determined  by  two  queries  to  be  a  pipe  connecting  an  intake  on  the  Raritan  River 
to  an  industrial  facility.  Many  complex  investigations  of  the  data  arc  possible  through  the  association  table 
tadSiteConveyance. 

The  Conveyance  attributes  include  classifications  of  the  type  (pipe,  aqueduct,  and  so  forth)  and  the 
functional  action  they  perform  in  the  water  network  (such  as  “From  intake  pipe  To  single  user”  as  shown  in 
figure  6).  Each  Conveyance  may  be  associated  with  one  or  more  Owners  through  the  tasConveyanceOwner 
table  (fig.  5). 

The  Transfer  entity  stores  the  individual  water-movement  estimate  or  measurement  made  on  each 
Conveyance  during  a  single  time  interval.  Each  Transfer  in  the  tblTransfer  table  is  uniquely  identified  by  a 
Transfer _ID  and  has  the  FK  field  Convey ance_ID  to  identify  the  Conveyance  to  which  the  Transfer  applies. 
All  Transfers  arc  time-dependent,  and  a  Transfer  includes  starting  and  ending  dates  and  the  time-interval 
classification  of  that  date  range  (for  example,  year  or  month).  Because  different  water-use  values  derived 
from  different  estimation  methods  must  be  stored  separately,  original  reported  volume  values  are  stored  in 
the  Volume  entity.  The  tblVolume  table  stores  the  reported/estimated  Volume  value  with  a  unique 
Volume_ID ,  along  with  its  original  units,  method  of  determination,  and  data  source.  One  Volume  for  each 
Transfer  is  designated  as  the  default,  and  its  value  is  converted  to  million  gallon  equivalents  and  stored  in 
the  tblTransfer  table  for  quick  retrieval.  The  Volume  entity,  therefore,  is  not  needed  to  retrieve  volume 
estimates  for  routine  summarization,  but  is  available  for  additional  details  about  the  original  Volumes  and 
alternative  estimates  stored  for  each  Transfer. 

The  last  core  entity  is  Owner.  An  Owner  is  a  person,  company,  municipality,  or  other  organization 
that  controls  and  maintains  Sites  and  Conveyances  and  can  serve  as  the  provider  of  data  (DataSource)  for 
Transfer  Volumes.  Each  Owner  is  uniquely  identified  in  the  tblOwner  table  by  an  Owner _ID.  Individual 
Owners  can  be  paid  of  an  Owner  organization,  so  a  ParentOwner_ID  value  is  identified  as  an  attribute  of  an 
Owner  record  when  applicable.  This  is  especially  useful  for  grouping  Sites  with  single  Owners  or  for 
exploring  hierarchies  of  ownership. 

The  sections  of  this  document  that  immediately  follow  describe  in  greater  detail  the  structure  of  the 
subject  areas  of  the  NJWaTr  model.  The  general  use  of  Addresses,  DataSources,  Permits,  Aliases,  and  User- 
Defined  Details  are  discussed  in  separate  sections. 


Site  Subject  Area 

The  Site  subject  area  focuses  on  the  tblSite  table  and  its  related  entities.  The  Site  subject  area  diagram 
is  shown  in  figure  7.  Each  Site  is  identified  by  a  unique  Site_ID.  Each  Site  also  is  strictly  classified  as  a 
particular  SiteType  and  has  a  functional  water-UseType  assignment.  For  example,  a  well  Site  could  be 
assigned  a  SiteType  (discussed  below)  value  of  “withdrawal  well”  and  a  UseType  value  of  “public  supply.” 
Sites  arc  paired  with  Conveyance _IDs  in  the  tadSiteConveyance  table,  which  connects  them  (relationally 
speaking)  in  a  direct  path  to  Conveyance  and  Transfer  information;  data  from  any  of  these  entities  arc 
available  at  the  Site  (or  Site  classification)  level. 

When  an  area  aggregate,  such  as  a  town,  is  to  be  used  as  a  Site,  multiple  Sites  arc  entered  into 
NJWaTr  to  represent  different  use  components,  or  layers,  for  the  area.  For  example,  a  town  aggregate  might 
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Figure  6.  A  hypothetical  example  of  Conveyance  data  in  NJWaTr  showing  records  in  table 
tadSite  Conveyance  highlighted  for  ConveyanceJD  =  28  and  indicating  From  Site_ID=  28 
and  To  Site_ID  =  3  (upper  left),  a  query  showing  the  identities  of  the  Sites  at  the  Conveyance 
ends  From  an  intake  pipe  To  an  industrial  facility  (upper  right),  and  a  query  showing  the 
properties  of  the  Conveyance  (bottom). 
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tbILocation 

LocationJD:  AutoNumber 


LocationScaleJD:  Integer  (FK)  r 

Location DetMethod_ID:  Long  Integer  (FK)  | 

LocationName:  Text(200)  | 

Location  Latitude:  Text(30) 

LocationLongitude:  Text(30) 

NJ Easting:  Text(50) 

NJNorthing:  Text(50) 

LocationMemo:  Memo 


tbIOwner 

OwnerJD:  AutoNumber  - 

OwnerTypeJD:  Integer  (FK) 

OwnerName:  Text(200) 

OwnerContact:  Text(200) 

OwnerPhone:  Text(25) 

OwnerMemo:  Memo 

ParentOwnerJD:  Long  Integer  (FK)  -j 


tdsSiteType 

SiteType ID:  Integer 

—  •  SiteTypeSubcategoryJD:  Integer  (FK) 
SiteType:  Text(50) 

SiteTypeMemo:  Memo 


tdsSiteTypeSubcategory 

- SiteTypeSubcategoryJD:  Integer 

—  -%  SiteTypeCategoryJD:  Integer  (FK) 
SiteTypeSubcategory:  Text(25) 


tdsSiteTypeCategory 

-  SiteTypeCategoryJD:  Integer 
SiteTypeCategory:  Text(25) 


tbISite 


Site  ID:  AutoNumber 


LocationJD:  Long  Integer  (FK) 
OwnerJD:  Long  Integer  (FK) 
SiteTypeJD:  Integer  (FK) 
UseTypeJD:  Integer  (FK) 
SiteName:  Text(IOO) 
SiteContact:  Memo 
SiteMemo:  Memo 


tadSiteUseType 


SiteJD:  Long  Integer  (FK) 
UseTypeJD:  Integer  (FK) 


UseTypeFraction:  Single 


tdsUseType 


UseTypeJD:  Integer 

— 

UseGroupJD:  Integer  (FK) 
UseTypeCode:  Text(2) 
UseType:  Text(50) 

•- 

tdsUseGroup 

UseGroupJD:  Integer 

UseGroupCode:  Text(2) 
UseGroup:  Text(50) 


tadUseConsumedFraction 


UseTypeJD:  Integer  (FK) 
Month:  Long  Integer 

ConsumedFraction:  Single 

tasSiteTypeDetailLabel 


tadSiteConveyance 

ConveyanceJD:  Long  Integer  (FK) 
FromOrTo:  Text(4) 

I  SiteJD:  Long  Integer  (FK) 


tadSiteResource 

^  SiteJD:  Long  Integer  (FK) 

Resource JD:  Long  Integer  (FK) 
CriticalAreaJD:  Integer  (FK) 
CriticaIZoneJD:  Integer  (FK) 
ConnectionCount:  Integer 


tadSiteDetail 


SiteJD:  Long  Integer  (FK) 
SiteDetailLabelJD:  Long  Integer  (FK) 
Site Detai I Eff ecti veDate :  Date/Ti me 


SiteDetailEndingDate:  Date/Time 
DataSourceJD:  Long  Integer  (FK) 
TimelntervalJD:  Integer  (FK) 
SiteDetailValue:  Text(50) 
SiteDetailMemo:  Memo 


tdxSiteDetailLabel 


SiteDetailLabelJD:  AutoNumber 

SiteDetailCategoryJD:  Long  Integer  (FK) 
Site  Detail  Label:  Text(50) 

IsNumericDetail:  Yes/No 

SiteDetailUnit:  Text(50) 
SiteDetailLabelMemo:  Memo 

tasSiteAddress 


Site_ID:  Long  Integer  (FK) 
AddressJD:  Long  Integer  (FK) 


tasSiteAlias 


SiteJD:  Long  Integer  (FK) 
AliasJD:  Long  Integer  (FK) 


V 


y 


tasSystemSite 


System  JD:  Long  Integer  (FK) 
SiteJD:  Long  Integer  (FK) 


tasSitePermit 


SiteJD:  Long  Integer  (FK) 
PermitJD:  Long  Integer  (FK) 


V 


y 


Figure  7.  Site  subject  area  tables,  fields,  and  relationships.  See  Explanation  following. 


EXPLANATION 


Functional  Table  Types 


Table  and  Relationship  Symbols 


tbl 


BASIC  DATA  TABLE;  tbl  prefix;  yellow 

DOMAIN,  STATIC;  tds  prefix;  blue 

DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 

ASSOCIATION,  SIMPLE;  tas  prefix;  white 

ASSOCIATION,  WITH  DATA;  tad  prefix;  green 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

0 - Optional  FK  value  (weak,  diamond) 


CHILD  END  OF  RELATIONSHIP  (dot) 


Field  Property  Indicators 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 

NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


K> 

L/i 


Figure  7.  Site  subject  area  tables,  fields,  and  relationships-Continued 


be  represented  by  separate  Sites  for  ground-water  withdrawal,  surface-water  withdrawal,  domestic  users, 
irrigation,  and  commercial  users.  This  partitioning  of  an  area  aggregate  into  separately  identified  and  use- 
classified  Site  records  allows  detailed  storage  of  water-use  Transfers  for  the  individual  components  of  the 
aggregate,  and  it  is  consistent  with  storage  of  point-located  Site  data.  By  storing  use  components  as  separate 
Sites  in  all  cases,  available  data  from  different  scales  can  be  entered,  and  data  summarization  is  greatly 
enhanced. 

Each  Site  record  contains  FKs  that  associate  it  with  a  single  Owner  and  a  single  Location,  both  of 
which  arc  attributes  of  the  Site.  Both  entities  have  descriptive  fields  of  their  own  that  arc  available  for  use 
with  the  Site  object  for  classification,  sorting,  and  grouping  Sites  as  needed.  In  particular,  the  Location  rep¬ 
resents  1  basic  data,  4  association,  and  9  domain  tables,  for  a  combined  total  of  48  non-key  fields  describing 
spatial,  geopolitical,  and  watershed  location  information  for  a  Site.  The  Location  and  Owner  subject  areas 
will  be  described  farther  on  in  separate  sections.  Both  the  Owner  and  Location  can  be  shared  by  different 
Sites  when  appropriate.  For  example.  Bottling  Company  X  (Owner)  has  a  plant  facility  (Location)  with  a 
well  and  an  on-site  treatment  plant.  The  well,  treatment  plant,  and  facility  itself  (place  of  water  use  for 
bottling)  would  be  entered  and  classified  as  separate  Sites  in  NJWaTr,  and  all  would  share  the  same 
Location  and  Owner. 

Each  Site  is  given  a  name  but  may  also  be  known  by  other  names  or  through  established  codes  used 
by  different  organizations.  To  accommodate  multiple  identification  methods  for  single  Sites,  association 
tables  arc  used  to  pair  Sites  with  Permits  and  Aliases  in  tasSitePermit  and  tasSiteAlias,  respectively. 
Likewise,  address  information  stored  for  a  Site  is  handled  by  an  association  with  an  Address  record  in 
tcisSiteAddress.  Storage  of  User-Defined  Details  about  a  Site  is  handled  through  the  tadSiteDetail  table.  The 
Permit,  Alias,  Address,  and  User-Defined  Details  subject  areas  arc  described  farther  on  in  separate  sections. 

Each  Site  is  described  by  a  number  of  domain  entities  that  classify  and  further  identify  the  attributes 
or  properties  of  a  Site.  These  include  the  SiteType  and  UseType,  and  each  domain  applies  a  different  stan¬ 
dardized  classification  to  an  individual  Site.  The  SiteType  is  a  nested  domain  of  tdsSiteTypeCategory, 
tdsSiteTypeSubcategory,  and  tdsSiteType  that  contain,  for  example,  the  values  “treatment,”  “pre-use,”  and 
“potable-water  treatment  plant,”  respectively. 

The  type  of  water  use  represented  by  a  Site  is  determined  by  a  UseType.  UseType  is  defined  in 
NJWaTr  using  New  Jersey  classifications  in  the  nested  domains  tdsUseGroup  and  tdsUseType  which 
have,  for  example,  the  nested  values  “Agricultural”  and  “Cranberries.”  An  optional  table, 
tadUseConsumedF faction,  is  provided  to  store  estimated  monthly  consumptive-use  profiles  for  each 
UseType  as  a  fraction  of  water  lost  to  the  atmosphere  for  a  particular'  month  at  a  Site.  The  data  provide  a 
means  to  create  consumptive  Transfers  for  Sites  that  have  different  UseTypes,  to  check  available  consump¬ 
tive  data  for  different  Sites  against  predicted  consumption  by  UseType,  or  to  develop  better  monthly  con¬ 
sumptive-use  profiles  for  each  type. 

Another  optional  table,  tadSiteUseType,  is  used  to  allow  Sites  with  a  designated  primary  UseType  to 
be  further  identified  as  having  secondary  uses.  The  tadSiteUseType  table  pairs  a  Site_ID  with  a  UseType _ID 
to  form  its  PK  and  has  an  additional  field,  UseTypeFraction,  to  store  the  percentage  of  that  UseType  in  the 
overall  classification  of  the  Site. 

A  third,  optional  Site-related  table,  tasSiteTypeDetailLabel,  pairs  SiteTypes  with  Label  terms  for  a 
User-Defined  Detail  to  establish  valid  combinations  of  types  and  labels.  This  table  can  be  used  to  enforce 
or  restrict  the  availability  of  certain  labels  to  certain  types  in  a  data-entry  application. 
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Sites  that  interact  directly  with  a  water  resource  such  as  a  river  or  reservoir  are  classified  using  the 
tdsSiteTypeCategory  domain  as  “resource  interactors.”  These  Sites  arc  associated  with  the  Resource  entity 
through  the  tadSiteResource  association  table,  whose  structure  was  discussed  earlier  in  the  description  of 
tad  functional  tables.  Each  resource-interactor  Site  is  paired  with  a  single  Resource,  and  the  number  of 
direct  connections  represented  by  the  pairing  (for  example,  the  number  of  intake  pipes  on  a  reservoir)  is 
stored  in  the  field  ConnectionCount.  If  a  Site  is  a  well  in  a  regulated  aquifer  it  may  be  assigned  to  a  Criti- 
calArea  and  CriticalZone;  the  domains  tdsCriticalArea  and  tdsCriticalZone  will  be  discussed  in  the 
“Resource  Subject  Area”  section. 

Sites  can  be  associated  with  other  Sites  through  the  tasSystemSite  association  table  to  form  named 
Systems.  A  System,  which  allows  any  user-defined  collection  of  Sites  to  be  handled  as  a  group,  is  discussed 
in  more  detail  in  the  “System  Subject  Area”  section. 

Although  each  user  implementation  of  NJWaTr  will  create  its  own  Site  entries,  three  generalized 
water-accounting  Sites  are  provided  for  users  in  the  tblSite  table.  The  first  Site  has  a  SiteName  of  “Atmo¬ 
sphere  (consumptive  use)”  and  represents  water  that  is  evaporated  or  incorporated  into  products.  This  Site 
is  used  as  the  receiving  (To)  end  of  a  Conveyance  to  capture  Transfer  Volumes  that  represent  consumptive 
use  for  another  Site;  all  Transfers  on  that  Conveyance  will  represent  consumptive  use  for  the  other  Site.  The 
second  Site  has  a  SiteName  of  “Unaccounted-for  water”  and  represents  the  combination  of  leakage  from  dis¬ 
tribution  systems  and  public  use  of  water,  such  as  hydrant  flushing,  fire  fighting,  and  street  sweeping.  This 
Site  also  is  used  as  the  receiving  (To)  end  of  a  Conveyance  to  capture  Transfer  Volumes  for  those  purposes 
from  another  Site  (for  example,  to  record  unaccounted-for  use  for  a  regional  or  local  distribution  system 
Site).  The  third  Site  has  a  SiteName  of  “Inflow  and  Infiltration  water”  and  represents  the  combination  of 
inflow  from  surface  water  and  infiltration  from  ground  water  into  a  wastewater-collection  system.  This  Site 
is  used  as  the  sending  (From)  end  of  a  Conveyance  to  capture  Transfer  Volumes  as  inputs  to  another  Site. 
These  three  generalized  Sites  are  used  at  either  the  From  or  To  end  of  a  Conveyance  as  appropriate  and  are 
convenient  for  identifying  and  gathering  the  Transfers  that  they  represent  (consumptive  use,  unaccounted- 
for  use,  and  inflow/  infiltration). 


Conveyance  Subject  Area 

The  Conveyance  subject  area  focuses  on  the  tblConveyance  table  and  its  related  entities.  The 
Conveyance  subject  area  diagram  is  shown  in  figure  8.  Each  Conveyance  is  identified  by  a  unique 
Conveyance  _ID.  Sites  arc  paired  with  Conveyance_IDs  in  the  tadSiteConveyance  association  table,  and 
Transfers  inherit  Conveyance _ID  as  an  attribute.  There  is  a  direct  path,  therefore,  connecting  Sites  to 
Transfers  through  the  Conveyance;  data  from  any  of  these  entities  arc  available  at  the  Conveyance  level  in 
the  database  model. 

A  Conveyance  initially  is  defined  as  a  record  in  the  tblConveyance  table,  but  it  needs  established 
endpoints  in  the  tadSiteConveyance  association  table  as  two  paired  Sites,  one  being  identified  as  the  source 
(From  end)  and  the  other  as  the  target  (To  end)  using  the  FromOrTo  field.  This  results  in  two  entries  in  the 
tadSiteConveyance  table  for  each  Conveyance.  Conveyances  arc  strictly  unidirectional;  therefore,  two  Con¬ 
veyances  arc  required  to  store  data  for  bi-directional  Transfers  between  two  specific  Sites  (four  records  in 
the  tadSiteConveyance  table).  Once  established,  a  Conveyance  serves  as  the  parent  to  one  or  more  water 
Transfers. 

As  described  in  the  previous  section,  three  special  Sites  are  included  in  NJWaTr  to  handle  consump¬ 
tive  water-use,  unaccounted-for  use,  and  inflow  and  infiltration  water.  The  Conveyances  created  To  the 
Sites  named  “Atmosphere  (consumptive  use)”  and  “Unaccounted-for  water”  will  anchor  water-network 
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Figure  8.  Conveyance  subject  area  tables,  fields,  and  relationships. 


Volume  losses  for  the  Sites  at  the  From  ends  of  those  Conveyances,  whereas  Conveyances  created  From  the 
“Inflow  and  Infiltration  water”  Site  will  handle  those  undefined  inputs  to  a  Site  at  the  To  end  of  the  Con¬ 
veyance.  All  consumptive  use  is,  therefore,  easily  recognized  by  its  Conveyance  to  the  Atmosphere  Site, 
and  the  tadSiteConveyance  table  can  be  used  to  quickly  retrieve  all  Sites  involved  in  consumptive  use.  The 
retrieval  of  unaccounted-for  water  losses  and  inflow/infiltration  water  inputs  arc  handled  in  the  same  way. 

A  Conveyance  may  have  one  or  more  Owners  responsible  for  control  and  maintenance,  and  this  is 
handled  by  pairing  Conveyances  with  Owners  in  the  association  table  tasConveyanceOwner.  Multiple 
ownership  assignment  is  useful,  for  example,  when  a  Conveyance  represents  water  exchange  between  two 
towns  and  exploring  the  water  network  connections  to  either  town  (the  Owner)  would  reveal  the  Convey¬ 
ance. 


Each  Conveyance  has  an  optional  name  ( Convey anceName )  and  is  provided  access  to  the  tblAlias 
table  as  needed  through  the  tasConveyanceAlias  association  table.  Storage  of  User-Defined  Details  about  a 
Conveyance  is  handled  through  the  tadConveyanceDetail  table.  The  Alias  and  User-Defined  Details  subject 
areas  arc  described  elsewhere. 

Two  domain  tables  arc  used  to  classify  each  Conveyance:  tdsConveyanceType  and 
tdsConveyance Action.  The  tdsConveyanceType  domain  includes  the  values  “pipe,”  “canal,”  “virtual,”  and 
others.  Virtual  Conveyances  arc  connections  between  Sites,  such  as  a  connection  between  a  town  and  a 
treatment  plant,  but  without  detailed  data  about  the  Conveyance  itself.  In  this  example,  the  actual  number 
of  pipes  may  not  be  important  or  even  known  but  identifying  the  connection  is  critical  to  capturing  Transfer 
information  between  the  town  and  treatment  plant. 

The  tdsConveyanceAction  domain  contains  a  ConveyanceActionPhrase  field  that  describes  the 
function  of  the  Conveyance  based  on  the  SiteTypes  at  the  source  and  target  ends,  for  example  “From  with¬ 
drawal  well  To  potable-water  treatment  plant.”  The  nested  domains  tdsConveyanceActionCategory  and 
tdsConveyanceAction  can  be  used  to  identify  Conveyances  that  serve  a  particular  function  within  the  water- 
use  network  or  to  contrast  Transfer/V olume  data  between  action  types,  such  as  comparing  ground-water 
withdrawals  sent  to  treatment  plants  with  ground-water  withdrawals  sent  directly  to  distribution  systems. 

Not  all  SiteTypes  can  be  paired  through  a  connection  (for  example,  a  withdrawal  well  should  not  lead 
to  a  river  intake  pipe),  so  the  ConveyanceAction  domain  is  static  and  contains  only  valid  combinations 
created  from  the  SiteType  domain  list.  The  purpose  of  the  static  ConveyanceAction  domain,  therefore,  is  to 
limit  the  possible  types  of  Site  connections.  Key  values  of  the  associated  SiteTypes  for  a  particular  Convey¬ 
anceAction  arc  stored  as  the  attributes  SiteTypeFromID  and  SiteTypeToID.  These  pseudo-key  fields  arc  not 
connected  directly  to  the  tdsSiteType  table  to  avoid  a  circular  relationship  in  the  model  (two  separate 
pathways  to  join  tables),  but  they  can  be  linked  through  a  query  whenever  needed  to  extend  the  Convey¬ 
anceAction  domain  manually  to  the  SiteType  domain.  The  ConveyanceActionPhrase  field  contains  values 
created  through  a  maintenance  query  (described  in  the  “Conveyance  Action  Phrase  Updates”  section)  to 
ensure  a  semantically  accurate  phrase  defined  by  the  SiteType  of  the  Sites. 


Transfer/Volume  Subject  Area 

The  Transfer/Volume  subject  area  focuses  on  the  tblTransfer  and  tblVolume  tables  and  their  related 
entities.  The  Transfer/Volume  subject  area  diagram  is  shown  in  figure  9.  Water  Transfers  between  Sites 
through  Conveyances  represent  the  most  detailed  data  in  NJWaTr,  and  storing  the  full  history  of  Transfers 
over  time  will  result  in  the  tblTransfer  and  tblVolume  tables  containing  more  records  than  other  tables  in  the 
NJWaTr  database.  Each  Transfer  is  identified  by  a  unique  Transfer _ID,  and  Transfers  inherit  the 
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Figure  9.  Transfer/Volume  subject  area  tables,  fields,  and  relationships. 


Conveyance_ID  of  their  parent  Conveyance  as  an  attribute  of  each  Transfer.  There  is,  therefore,  a  direct  re¬ 
lational  pathway  to  Site  and  Conveyance  information  from  the  Transfer  level  of  the  database  model.  Details 
of  each  Transfer  in  original  reporting  units  are  stored  in  the  table  tblVolume. 

Transfers  are  time  dependent.  Each  Transfer  is  bounded,  inclusively,  by  its  two  date  fields, 
TransferEJfectiveDate  and  TransferEndingDate.  The  interval  category  that  the  date  range  defines  is  classi¬ 
fied  by  a  value  from  the  tdsTimelnterval  domain  table  (“year,”  “month,”  and  so  forth).  It  is  assumed  that  a 
single-day  datum  represents  the  smallest  recording  interval  for  Transfer/Volume  data.  The  Timelnterval 
domain  is  useful  for  aggregating  data  from  different  time  scales  and  for  analyzing  the  occurrence  frequency 
of  different  scales  for  various  Conveyance  and  Site  types.  Other  time  scales — fiscal  years  (Federal  and 
state),  water  years,  and  seasons — can  be  developed  through  queries  on  the  bounding  date  fields  and  arc  not 
designed  into  the  database. 

NJWaTr  specifications  require  that  Volumes  for  a  specific  Transfer  be  allowed  to  vary  on  the  basis 
of  different  determination  methods.  This  facilitates  study  of  differences  in  the  determination  methods  used 
for  the  summarization  and  reporting  of  water-use  activities.  Original  Volume  values  (as  provided  by  the 
DataSource),  therefore,  are  stored  along  with  their  descriptive  attributes  in  the  table  tblVolume.  The  rela¬ 
tionship  between  tblTransfer  and  tblVolume  is  modeled  as  one-to-many  with  many  Volume  estimate  alter¬ 
natives  possible  for  each  Transfer.  When  there  is  more  than  one  Volume  record,  a  field  in  tblVolume , 
IsDefaultVolume,  identifies  the  particular  Volume  record  to  be  associated  by  default  with  the  Transfer;  this 
Volume  is  converted  to  common  units  and  stored  in  the  VolumeMG  field  in  the  tblTransfer  table  using  a 
maintenance  query  described  in  the  section  “Volume  Conversion  to  Common  Units  and  Updating  Trans¬ 
fers.”  When  only  a  single  Volume  is  stored  for  a  Transfer,  it  is  always  the  default  Volume.  Having  a  single 
default  Volume  stored  in  converted  form  in  the  tblTransfer  table  also  means  that,  for  most  data  exploration 
and  reporting  activities,  the  tblVolume  table  and  its  associated  domains  arc  not  needed. 

The  original  data  for  each  Transfer  are  stored  in  the  tblVolume  table.  The  RawVolumeValue  field 
stores  the  numeric  paid  of  a  reported  Volume  value.  For  example,  “1.45”  would  be  stored  for  1.45  thousand 
cubic  feet.  It  is  important  to  store  all  Volumes  in  their  reported  form  to  facilitate  checking  against  original 
DataSources.  Within  the  tblVolume  table,  the  RawVolumeValue  is  associated  with  its  original  VolumeUnit, 
its  method  of  determination  (nested  domain  of  VolumeMethod  and  parent  Category),  a  DataSource,  and  the 
name/affiliation  of  the  Staff  responsible  for  the  entry.  The  tdxVolumeUnit  domain  table  represents  a  domain 
cluster  and  allows  a  VolumeUnit  to  be  created  from  any  combination  of  decimal  and  quantity  dimensions 
used  in  the  original  reporting  units  (for  example.  Volumes  reported  in  thousand  cubic  feet  have  separate  unit 
component  terms  of  “thousand”  and  “cubic-feet”).  Each  VolumeUnit  also  is  provided  with  a  value  for  the 
MGConversion  field,  which  is  the  value  by  which  the  RawVolumeValue  is  multiplied  to  convert  it  to 
common  units  regardless  of  the  reporting  units.  The  RawVolumeValue  is  converted  on  the  basis  of  the  Vol¬ 
umeUnit  to  an  equivalent  value  in  million  gallons  (MG)  units,  and  that  converted  Volume  value  is  stored  in 
the  tblTransfer  table  in  the  field  VolumeMG. 

During  initial  data  entry  or  batch  loading,  VolumeMG  in  tblTransfer  is  assigned  a  default  value  of 
“-1”  for  new  Transfer  records,  and  a  maintenance  query  (described  in  the  “Volume  Conversion  to  Common 
Units  and  Updating  Transfers”  section)  is  run  to  apply  the  VolumeUnit  MGConversion  against  the 
RawVolumeValue  in  order  to  update  the  Transfer  VolumeMG  value.  The  conversion  factors  arc  developed 
for  any  VolumeUnit  combination  by  automatically  creating  the  product  of  each  component  conversion 
(decimal  and  quantity).  When  new  VolumeUnits  arc  added  to  the  domain,  a  maintenance  query  (described 
in  the  “Volume  Unit  Updates”  section)  is  used  to  update  the  VolumeUnitPhrase  and  MGConversion  fields 
in  tdxVolumeUnit  on  the  basis  of  the  selection  of  a  unique  combination  of  components.  The  tdxVolumeUnit 
table  also  could  be  used  in  reverse,  through  queries,  to  convert  the  commonly  used  million  gallons, 
VolumeMG  values,  to  any  other  units  desired. 
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One  additional  feature  of  the  Transfer/Volume  subject  area,  the  tdxVolumeDetail  table,  is  shown  in 
figure  9.  Additional  data  storage  is  provided  for  variables  that  arc  not  known  in  advance  or  for  variables  that 
arc  associated  with  some  Volumes  but  not  others.  This  is  accomplished  through  the  use  of  a  User-Defined 
Detail  table.  (User-Defined  Detail  tables  are  discussed  in  the  “User-Defined  Details”  section.)  The  associ¬ 
ation  of  a  Volume_ID  with  a  VolumeDetail  Label_ID  and  a  VolumeDetail  in  the  tadVolumeDetail  table  can 
accommodate  any  optional  attributes  for  Volumes,  for  example,  “Accuracy.”  Accuracy  values  can  be  asso¬ 
ciated  with  each  Volume  by  assigning  a  value  of  “Accuracy”  to  a  record  in  the  VolumeDetailLabel  field  of 
the  tdxVolumeDetailLabel  domain  and  recording  the  accuracy  estimate  in  the  VolumeDetail  field  for  each 
Volume_ID.  In  addition,  a  note  about  the  definition  of  accuracy  for  the  NJWaTr  implementation  can  be 
entered  in  the  VolumeDetailLabelMemo  field. 


Location  Subject  Area 

The  Location  subject  area  focuses  on  the  tblLocation  table  and  its  related  entities.  The  Location 
subject  area  diagram  is  shown  in  figure  10.  Location  is  modeled  as  an  attribute  of  a  Site.  The  Location_ID 
as  a  FK  field  in  the  tblSite  table  provides  the  full  collection  of  Location  attributes  and  related  domains  to 
individual  Sites.  Through  the  Site’s  relationships.  Location  fields  can  be  used  as  attributes  that  also  provide 
spatial  characterization  of  Conveyances  and  Transfers.  A  single  Location  may  accurately  serve  more  than 
one  Site  if  they  occur  in  the  same  place,  such  as  individual  Site-level  objects  that  represent  various  water- 
use  types  (for  example,  livestock  or  irrigation)  of  an  aggregate  Site.  Site  aggregates  were  discussed  previ¬ 
ously  in  the  “Site  Subject  Area”  section. 

Each  Location  is  identified  by  a  unique  Location_ID  and  characterized  by  two  domains  that  represent 
LocationScale  (point,  or  various  area  categories)  and  the  method  used  to  determine  a  Location  (Location- 
DetMethod).  Optional  fields  are  provided  for  a  LocationName ,  the  mapping  coordinates  LocationLatitude 
and  LocationLongitude,  and  the  New  Jersey  grid  coordinates  NJEasting  and  NJNorthing.  Mapping  coordi¬ 
nates  can  store  values  that  represent  a  point  location  or  the  centroid  of  a  larger  area. 

A  Location  is  associated  with  a  geopolitical  state,  county,  and  MCD  nested  domain  hierarchy. 
Although  nested,  the  geopolitical  domains  are  each  associated  separately  with  tblLocation  using  the  associ¬ 
ation  tables  tadLocationState ,  tadLocationCounty,  and  tadLocationMCD.  Each  association  table  is  used  to 
pair  a  Location  with  one  or  more  of  the  geopolitical  selections,  along  with  the  proportion  of  the  Location 
represented  by  the  individual  pairings  using  a  Fraction  field.  This  allows  an  area  Location  that  overlays 
parts  of  two  towns,  for  example,  to  indicate  the  fraction  of  the  Location  represented  by  each  town.  This 
information  can  be  used  to  apportion  water-use  activities  for  an  area  Site  Location  among  the  individual 
geopolitical  areas.  When  more  than  one  item  from  the  domain  is  associated  with  a  single  Location,  one  of 
the  associates  should  be  designated  as  the  primary  selection  to  be  retrieved  by  default  with  the  Location  by 
having  a  “Yes”  value  in  the  Is  Primary  field  in  the  association  table;  all  other  associates  would  be  given  a 
“No”  value.  When  only  a  single  item  from  a  domain  is  associated  with  a  Location,  it  is  designated  the 
primary  selection. 

The  State  of  New  Jersey  is  divided  into  six  Drought  Regions  that  arc  listed  in  the  domain  table 
tdsDroughtRegion.  Because  single  towns  (MCD-scale)  belong  entirely  to  a  single  Drought  Region,  the 
tdsMCD  domain  includes  a  FK  field  that  identifies  the  Drought  Region  to  which  it  belongs.  Drought  Region 
classification,  therefore,  also  is  available  to  counties  and  states  and  to  all  water-transfer  activities  through 
the  Location’s  Site(s)  and  related  entities. 

Locations  also  can  be  associated  with  one  or  more  standard  hydrologic  units  through  the  association 
table  tadLocationHUC.  The  tdsHUC  domain  contains  a  list  of  the  933  New  Jersey  14-digit  watersheds, 
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EXPLANATION 


tdsLocationScale 

LocationScaleJD:  Integer 
LocationScale:  Text(50) 


tdxLocationDetMethod 

LocationDetMethodJD:  AutoNumber 
LocationDetMethod:  Text(50) 


tbILocation 

tbISite 

LocationJD:  AutoNumber 

— 

SiteJD:  AutoNumber 

1 - -• 

1 - -• 

LocationScaleJD:  Integer  (FK) 
LocationDetMethodJD:  Long  Integer  (FK) 
LocationName:  Text(200) 

LocationLatitude:  Text(30) 
LocationLongitude:  Text(30) 

NJEasting:  Text(50) 

NJNorthing:  Text(50) 

LocationMemo:  Memo 

—  • 

LocationJD:  Long  Integer  (FK) 
Owner  lD:  Long  Integer  (FK) 
SiteTypeJD:  Integer  (FK) 
UseTypeJD:  Integer  (FK) 
SiteName:  Text(IOO) 
SiteContact:  Memo 

SiteMemo:  Memo 

tdsMCD 


00 


MCDJD:  Integer 


CountyJD:  Integer  (FK) 
DroughtRegionJD:  Integer  (FK) 
StateMCDCode:  Text(7) 
MCDCode:  Text(5) 

MCDType:  Text(20) 

MCDName:  Text(50) 
MCDShortName:  Text(50) 
MCDLatitude:  Text(30) 
MCDLongitude:  Text(30) 


tdsCounty 

■  —  County_ID:  Integer 

StateJD:  Integer  (FK) 
StateCountyCode:  Text(5) 
CountyCode:  Text(3) 
CountyName:  Text(50) 
CountyShortName:  Text(50) 
CountyLatitude:  Text(30) 
CountyLongitude:  Text(30) 


tadLocationMCD 


LocationJD:  Long  Integer  (FK) 
MCDJD:  Integer  (FK) 


MCDFraction:  Single 
IsPrimaryMCD:  Yes/No 


tdsDroughtRegion 


DroughtRegionJD:  Integer 


DroughtRegionCode:  Text(5) 
DroughtRegion:  Text(50) 


tadLocationCounty 


LocationJD:  Long  Integer  (FK) 
CountyJD:  Integer  (FK) 

CountyFraction:  Single 
IsPrimaryCounty:  Yes/No 


tdsState 

StateJD:  Integer 

CountryAbbrv:  Text(3) 
StateCode:  Text(2) 
StateAbbrv:  Text(2) 
StateName:  Text(50) 
StateLatitude:  Text(30) 
StateLongitude:  Text(30) 


tadLocationState 


LocationJD:  Long  Integer  (FK) 
StateJD:  Integer  (FK) 


StateFraction:  Single 
IsPrimaryState:  Yes/No 

v  J 


tadLocationHUC 


Location_ID:  Long  Integer  (FK) 
HUCJD:  Integer  (FK) 

HUCFraction:  Single 
IsPrimaryhlUC:  Yes/No 


tdsHUC 


HUCJD:  Integer 


WatershedCode:  Text(20) 
WaterMgmntAreaJD:  Integer  (FK) 
HUC14:  Text(14) 

HUC14Name:  Text(50) 

HUC1 1 :  T ext(  11) 

HUC1 1  Name:  Text(50) 

HUC8:  Text(8) 

HUC8Name:  Text(50) 


tdsWaterMgmntArea 


WaterMgmntAreaJD:  Integer 

WaterRegionJD:  Integer  (FK) 
WaterMgmntAreaCode:  Text(50) 
WaterMgmntArea:  Text(50) 


i 


tdsWaterRegion 

WaterRegionJD:  Integer 

WaterRegionCode:  Text(50) 
WaterRegion:  Text(50) 


Functional  Table  Types 


BASIC  DATA  TABLE;  tbl  prefix;  yellow 


DOMAIN,  STATIC;  tds  prefix;  blue 


tdx 


DOMAIN.  USER-EXTENDABLE;  tdx  prefix;  gray 


tad 


ASSOCIATION,  WITH  DATA;  tad  prefix;  green 


Table  and  Relationship  Symbols 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 
field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 
the  PK) 

STRONG  RELATIONSHIP 
WEAK  RELATIONSHIP 


PARENT  END  OF  RELATIONSHIP 


Mandatory  FK  value  (strong,  no  symbol) 
Mandatory  FK  value  (weak,  no  symbol) 


CHILD  END  OF  RELATIONSHIP  (dot) 


Field  Property  Indicators 


PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 


(FK)  FOREIGN  KEY  FIELD 

(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


Figure  10.  Location  subject  area  tables,  fields,  and  relationships. 


along  with  their  higher  11-  and  8-digit  codes  and  basin  names.  This  could  have  been  modeled  as  a  nested 
hierarchy,  but  the  use  of  the  denormalized  form  of  this  static  domain  is  convenient  when  each  Location  is 
required  to  be  associated  with  a  14-digit  HUC.  Because  a  single  area  Location  may  cross  basin  boundaries, 
more  than  one  HUC  may  be  associated  with  it,  and  the  association  table  allows  storage  of  the  fraction  of  the 
Location  in  each  HUC.  One  HUC  may  be  designated  as  the  primary  selection  from  the  domain  to  be  used 
by  default. 

The  State  of  New  Jersey  is  divided  into  five  Water  Regions,  and  each  of  those  is  further  subdivided 
into  Watershed  Management  Areas  (Hoffman  and  Lieberman,  2000).  Watershed  Management  Areas  arc 
represented  in  NJWaTr  by  the  nested  domains  tdsWoterRegion  and  tdsWaterMgmntArea.  Each  14-digit 
HUC  is  associated  with  only  one  Water  Management  Area,  so  the  tdsHUC  domain  contains  a  FK  field  that 
points  to  the  tdsWaterMgmntArea  domain.  In  this  way,  each  14-digit  HUC  is  classified  by  Watershed  Man¬ 
agement  Area  and  its  parent  Water  Region. 

Each  spatial  domain  table  has  a  single  record  coded  as  “none  identified.”  This  allows  a  Site  Location 
to  be  defined  at  a  large  scale  (for  example,  county-scale  data  are  not  applicable  to  individual  MCDs)  or  as 
an  irregular  area  that  does  not  correspond  to  geopolitical  boundaries,  such  as  a  regional  distribution  system. 
For  larger-than-MCD  area  Locations,  the  tadLocationMCD  table  would  pair  the  Location  with  the  MCD 
record  that  represents  “unidentified;”  for  larger-than-County  Locations,  both  the  county  and  MCD  associa¬ 
tion  tables  would  classify  the  Location  as  unidentified  for  those  scales. 


Owner  Subject  Area 

The  Owner  subject  area  focuses  on  the  tblOwner  table  and  its  related  entities.  The  Owner  subject  area 
diagram  is  shown  in  figure  11.  An  Owner  is  a  person,  company,  municipality,  or  other  organization  that 
controls  and  maintains  a  Site,  Conveyance,  or  Resource,  or  that  can  serve  as  the  provider  of  a  DataSource 
for  Transfer  Volumes,  Permit  assignments,  and  User-Defined  Details  in  the  database.  Each  Owner  is  iden¬ 
tified  by  an  Owner_ID  value;  aggregate  areas  represented  as  single  Sites,  such  as  a  town,  may  have  no 
Owner  in  this  context  and  would  be  assigned  an  Owner_ID  corresponding  to  a  value  of  “No  Owner.” 
Different  kinds  of  Owners  are  classified  through  the  tdsOwnerType  domain  (for  example,  “Private,” 
“Municipal,”  or  “State”).  Owners  arc  further  described  by  fields  for  OwnerName,  OwnerContact,  and 
OwnerPhone,  and  an  Owner’s  Address  is  handled  by  an  association  through  the  tasOwner Address  table 
with  the  tblAddress  table  (to  be  discussed  in  the  “Address  Subject  Area”  section). 

Sites,  Resources,  and  DataSources  arc  associated  with  a  single  Owner  by  inheriting  the  Owner _ID  as 
a  FK  attribute.  The  absence  of  a  valid  Owner  assignment  is  indicated  by  using  the  Owner_ID  =  “0”  record 
coding  for  “No  Owner.”  Conveyances  can  have  one  or  more  Owners  (for  example,  recognizing  joint 
ownership  of  a  connection  between  towns),  which  is  accommodated  through  the  tasConveyanceOwner  as¬ 
sociation  table.  Owners  also  can  be  associated  with  one  or  more  Permits,  which  is  accommodated  through 
the  tasOwnerPermit  table. 

Individual  Owners  can  be  identified  as  paid  of  an  Owner  organization  through  the  recursive  hierar¬ 
chical  association  of  a  ParentOwner_ID  with  a  different  Owner  record  (a  self-join).  Nesting  of  Owners 
provides  a  way  to  group  Sites  and  Conveyances  into  actual  organizational  units  and  to  explore  hierarchies 
of  ownership. 
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tasConveyanceOwner 

ConveyanceJD:  Long  Integer  (FK) 
OwnerJD:  Long  Integer  (FK) 


tdxDataSource 


DataSourceJD:  AutoNumber 

OwnerJD:  Long  Integer  (FK) 
DataSource:  Text(75) 
DataSourceMemo:  Memo 


tasOwner  Add  ress 


OwnerJD:  Long  Integer  (FK) 
AddressJD:  Long  Integer  (FK) 


V 


tasOwnerPermit 


OwnerJD:  Long  Integer  (FK) 
PermitJD:  Long  Integer  (FK) 


tbIConveyance 

ConveyanceJD:  AutoNumber 

ConveyanceTypeJD:  Integer  (FK) 
ConveyanceActionJD:  Integer  (FK) 
ConveyanceName:  Text(200) 
ConveyanceMemo:  Memo 


Functional  Table  Types 


tbl 


BASIC  DATA  TABLE;  tbl  prefix;  yellow 

DOMAIN,  STATIC;  tds  prefix;  blue 

DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 

ASSOCIATION,  SIMPLE;  tas  prefix;  white 


EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

' -  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

0 - Optional  FK  value  (weak,  diamond) 


(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


—  CHILD  END  OF  RELATIONSHIP  (dot) 


Figure  11.  Owner  subject  area  tables,  fields,  and  relationships. 


Resource  Subject  Area 

The  Resource  subject  area  focuses  on  the  tblResource  table  and  related  entities.  The  Resource  subject 
area  diagram  is  shown  in  figure  12.  The  NJWaTr  model  provides  the  tblResource  table  to  store  identification 
information  for  all  aquifers,  rivers,  streams,  reservoirs,  lakes,  ponds,  and  estuaries  associated  with  water- 
use  activities. 

Resources  should  not  be  equated  with  Locations  in  NJWaTr.  Locations  serve  to  identify  the  places 
where  Sites  reside,  whereas  Resources  identify  water  bodies  in  the  major  categories  of  aquifer,  river/stream, 
and  reservoir,  among  others.  Resources  are  independent  of  Sites  although  those  Sites  that  interact  with  a 
water  Resource  will  likely  have  a  Location  that  matches  the  position  of  some  part  of  its  associated  Resource. 
To  meet  potential  future  needs,  the  Resource  subject  area  entities  and  attributes  can  extend  NJWaTr  by 
linking  to  hydrologic  and  geopolitical  areas,  gage  information,  ecology,  and  other  water-body  specific  data. 

A  Site  that  interacts  with  a  Resource  is  classified  as  a  “resource  interactor”  (SiteTypeCategory)  and 
is  paired  with  a  single  Resource  in  the  tadSiteResource  association  table  that  was  discussed  previously  in 
the  description  of  tad  tables.  The  table  pairs  a  Site  with  a  single  Resource  and  adds  an  optional  field, 
ConnectionCount,  to  record  the  number  of  connections  represented  by  the  pairing  (individual  pipes  or 
wells).  Two  domains  also  arc  used  to  classify  the  individual  Site-Resource  combination,  tdsCriticalArea 
and  tdsCriticalZone.  These  classifications  concern  diversion  sources  or  withdrawals  in  either  of  two 
regulated  aquifer  areas  defined  within  New  Jersey  (Hoffman  and  Lieberman,  2000).  These  arc  not  fully 
nested  domains  so  they  arc  applied  individually  to  the  Site-Resource  pairings.  Sites  that  arc  resource  inter¬ 
actors  located  outside  the  critical  areas  receive  an  assignment  of  "not  applicable"  from  the  tdsCriticalArea 
domain.  Sites  receive  the  appropriate  tdsCriticalZone  assignment  on  the  basis  of  the  type  and  location  of 
withdrawal.  From  the  relationships  through  the  tadSiteResource  table,  wells  associated  with  defined  critical 
areas  are  recognized,  and  all  withdrawals  and  releases  for  any  water  body  listed  in  the  tblResource  table  arc 
available. 

Each  Resource  is  identified  by  a  Resource_ID ,  a  mandatory  ResourceName ,  and  an  optional  Re- 
sourceCodeName.  Two  name  fields  arc  used  because  names  of  water  bodies  are  typically  redundant  even 
within  the  same  watershed.  The  stream  name  of  Mill  Creek  in  New  Jersey  is  a  good  example.  The 
ResourceName  field  is  intended  for  storage  of  the  name  in  common  use  (for  example,  “Mill  Creek”), 
whereas  the  ResourceCodeName  field  is  used  for  an  extended  version  of  the  name  that  provides  unique 
identification  information.  A  standard  naming  rule  for  ResourceCodeName  has  not  been  specified  in 
NJWaTr,  but  the  suggested  practice  is  to  distinguish  different  water  bodies  with  the  same  ResourceName  in 
the  database  by  including  the  name  of  the  town  nearest  its  source  in  the  ResourceCodeName.  Thus,  the 
ResourceCodeNames  of  “Mill  Creek  near  Wildwood  Crest,  NJ”  and  “Mill  Creek  near  Ocean  City,  NJ”  arc 
distinguishable  although  both  have  the  same  common  name  ( ResourceName ),  “Mill  Creek.”  That  distinc¬ 
tion  facilitates  searches  in  the  database  for  Sites  that  interact  with  only  one  of  those  water  Resources.  De¬ 
velopment  and  implementation  of  the  naming  scheme  does  not  affect  the  current  structure  of  NJWaTr  in  any 
way  because  only  the  contents  of  the  ResourceCodeName  field  are  affected. 

Each  Resource  receives  a  FK  to  identify  it  with  an  Owner  from  the  tblOwner  table.  Where  there  is 
no  actual  Owner  (such  as  for  any  water  Resource  held  in  trust  by  the  State  of  New  Jersey),  a  “Not  Owned” 
selection  from  the  tblOwner  table  is  used.  In  addition,  the  nested  ResourceType  and  WaterBodyType 
domains  provide  a  classification  system  for  individual  Resources.  The  tdsResourceType  domain  table  iden¬ 
tifies  ground-  or  surface-water  sources  and  a  salinity  attribute  (freshwater,  brackish,  or  saline)  and  applies 
a  ResourceType  name  to  each  combination  (such  as  “surface-water,  fresh”).  These  basic  classifications  then 
arc  assigned  as  parent  categories  for  individual  selections  in  the  tdsWaterBodyType  table,  which  includes 
values  such  as  “Reservoir,”  “River,”  and  “Estuary.”  These  domains  and  their  relationships  in  NJWaTr  allow 
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tbIResource 

-  ResourceJD:  AutoNumber 


--a 


tadSiteResource 


tdsCriticalArea 


Critical Area_l D :  Integer 

CriticalAreaCode:  Text(5) 
Critical  Area:  Text(255) 


j 


i - •  WaterBodyTypeJD:  Integer  (FK) 

I  — •  OwnerJD:  Long  Integer  (FK) 

|  ResourceName:  Text(200) 

|  ResourceCodeName:  Text(200) 

|  ResourceMemo:  Memo 


tbIOwner 

OwnerJD:  AutoNumber 

OwnerTypeJD:  Integer  (FK) 
OwnerName:  Text(200) 
OwnerContact:  Text(200) 
OwnerPhone:  Text(25) 
OwnerMemo:  Memo 
ParentOwner  ID:  Long  Integer  (FK) 


tdsResourceType 

ResourceTypeJD:  Integer 

GWorSW:  Text(2) 

Salinity:  Text(2) 
ResourceType:  Text(50) 


tdsWaterBodyT  y  pe 


WaterBodyTypeJD:  Integer 

ResourceTypeJD:  Integer  (FK) 
WaterBodyType:  Text(30) 


J 


tasWaterBodyDetailLabel 


WaterBodyTypeJD:  Integer  (FK) 
ResourceDetailLabel_ID:  Long  Integer  (FK 


Functional  Table  Types 


tad 


tbl 

tdx 

BASIC  DATA  TABLE; 
tbl  prefix;  yellow 

tds 

tas 

DOMAIN,  STATIC; 
tds  prefix;  blue 

DOMAIN,  USER-EXTENDABLE; 
tdx  prefix;  gray 

ASSOCIATION,  SIMPLE; 
tas  prefix;  white 

ASSOCIATION,  WITH  DATA; 
tad  prefix;  green 


Figure  12.  Resource  subject  area  tables,  fields,  and  relationships. 


tasResourceAlias 


ResourceJD:  Long  Integer  (FK) 
AliasJD:  Long  Integer  (FK) 


tadResourceStructure 


ParentResourceJD:  Long  Integer  (FK) 
ChildResourceJD:  Long  Integer  (FK) 


ParentResourceFraction:  Single 
IsPrimaryResource:  Yes/No 


tadResourceDetail 


ResourceJD:  Long  Integer  (FK) 
ResourceDetailLabelJD:  Long  Integer  (FK)  |#- 
ResourceDetailEffectiveDate:  Date/Time 


Resource  Detail  Ending  Date:  Date/Time 
DataSourceJD:  Long  Integer  (FK) 
ResourceDetail:  Text(50) 
ResourceDetailMemo:  Memo 


tdxDataSource 

DataSourceJD:  AutoNumber 

•  OwnerJD:  Long  Integer  (FK) 
DataSource:  Text(75) 
DataSourceMemo:  Memo 


J 


tdxResourceDetailLabel 


ResourceDetailLabelJD:  AutoNumber 

ResourceDetailLabel:  Text(50) 
ResourceDetailLabelMemo:  Memo 

EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

O- - Optional  FK  value  (weak,  diamond) 


(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


CHILD  END  OF  RELATIONSHIP  (dot) 


the  identification  of  those  Sites  (and,  therefore,  their  Conveyances  and  Transfers)  involved  with  different 
types  of  water  Resources. 

Sometimes  a  single  Site’s  interaction  with  water  Resources  cannot  be  limited  to  a  single  Resource, 
for  example  when  a  deep  well  has  multiple  openings  in  different  aquifers.  The  tadSiteResource  table  does 
not  allow  multiple  Resources  per  Site,  so  another  method  is  provided  to  store  and  decode  a  composite 
Resource  for  a  Site.  The  composite  (parent)  Resource  is  entered  as  a  single  record  in  tblResource  and  given 
an  appropriate,  informative  ResourceName',  the  subcomponent  (child)  Resources  of  the  composite  also  arc 
entered  individually.  The  table  tadResourceStructure,  discussed  previously  in  the  tad  functional  type  de¬ 
scription,  pairs  the  Resource_ID  of  the  composite  Resource  (as  ParentResource_ID )  with  the  Resource_ID 
of  each  subcomponent  Resource  (as  ChildRe source _ID),  along  with  an  optional  fraction  of  the  composite 
parent  represented  by  the  child.  The  structure  table  allows  composite  Resources  to  be  recognized  by  their 
components,  components  to  be  recognized  as  occasionally  associated  with  others,  and  all  Sites  associated 
with  a  particular  Resource  to  be  revealed  even  when  the  specified  Resource  is  only  one  paid  of  a  larger 
composite. 

Resources  can  have  Aliases  stored  in  the  tblAlias  table  through  the  tasResourceAlias  association 
table.  The  ability  to  store  optional  information  about  any  particular  Resource  is  provided  by  the 
tadResourceDetail  table  and  its  associated  tdxResourceDetailLabel  and  tdxDataSource  tables.  This  allows 
dams  to  be  associated  with  reservoirs,  fisheries  to  be  associated  with  particular  rivers,  and  any  other  optional 
attributes  to  be  classified  and  stored  as  needed.  Both  the  Alias  and  User-Defined  Details  subject  areas  arc 
described  elsewhere  in  this  report.  A  related,  optional  table,  tasWaterBodyDetailLabel,  pairs  WaterBody- 
Types  with  Label  terms  for  a  User-Defined  Detail  to  establish  valid  combinations  of  types  and  labels.  This 
table  can  be  used  to  enforce  or  restrict  the  availability  of  certain  labels  to  certain  types  in  a  data-entry 
application. 


System  Subject  Area 

The  core  NJWaTr  data  structures  that  join  Sites  through  unidirectional  Conveyances  describe  a  water 
network  by  allowing  each  Site  to  show  the  characteristics  of  its  input  and  output  connections  and  related 
Transfers.  Sites  can  be  grouped  by  their  descriptive  attributes  and  Type  domains,  and  by  the  attributes  of 
their  Conveyances,  Transfers/Volumes,  Locations,  Owners,  and  associated  Resources.  For  convenience,  an 
additional  grouping  of  Sites  called  Systems  can  be  set  up  in  NJWaTr  to  gather  Sites  for  any  purpose,  regard¬ 
less  of  whether  or  not  they  arc  connected  or  share  any  attributes.  For  example,  a  public-supply  System  could 
be  created  to  include  all  Sites  that  represent  withdrawals  (wells,  intakes),  treatment,  and  distribution.  Other 
Systems  could  include  the  cluster  of  Sites  that  make  up  a  fish  hatchery  operation,  an  industrial  complex,  the 
distribution  network  of  Sites  for  a  town,  a  regional-collection  system,  or  the  collection  of  Sites  handled  as 
a  discrete  unit  during  data  entry. 

Three  tables — tdxSystem ,  tdxSystemType,  and  tasSystemSite — are  required  to  set  up  System-level 
identities  for  Sites  in  NJWaTr,  and  these  tables  and  their  relationships  are  illustrated  in  figure  13.  System- 
identity  information  is  stored  in  the  table  tdxSystem.  Each  System  is  given  a  unique  System _ID  and  a 
SystemName.  A  SystemType  classification  is  assigned  from  the  tdxSystemType  domain  and  can  include 
such  values  as  “Public  Supplier”  and  “Public  Wastewater  System.”  An  association  table,  tasSystemSite ,  is 
used  to  pair  individual  Sites  (from  tblSite)  with  individual  Systems.  A  System  can  consist  of  any  number  of 
Sites,  and  each  Site  can  be  a  member  of  any  number  of  Systems.  This  structure  allows  the  NJWaTr  user  to 
select  all  Sites  associated  with  a  System  or  to  identify  all  Systems  associated  with  a  Site  and  to  generate 
membership  statistics,  such  as  the  number  and  type  of  Sites  that  belong  to  three  or  more  Systems. 
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tbISite 

Site  ID:  AutoNumber 


LocationJD:  Long  Integer  (FK) 
OwnerJD:  Long  Integer  (FK) 
SiteTypeJD:  Integer  (FK) 
UseTypeJD:  Integer  (FK) 
SiteName:  Text(IOO) 
SiteContact:  Memo 
SiteMemo:  Memo 


tasSystemSite 

SystemJD:  Long  Integer  (FK)  ^ 
SiteJD:  Long  Integer  (FK) 


tdxSystem 

System_ID:  AutoNumber 


SystemTypeJD:  Long  Integer  (FK) 
SystemName:  Text(200) 
SystemMemo:  Memo 
ParentSystem_ID:  Long  Integer  (FK) 


tdxSystemType 


SystemType_ID:  AutoNumber 

SystemType:  Text(40) 
SystemTypeMemo:  Memo 


VO 


EXPLANATION 


Functional  Table  Types 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


tbl _ 

BASIC  DATA  TABLE;  tbl  prefix;  yellow 


DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 


tas _ 

ASSOCIATION,  SIMPLE;  tas  prefix;  white 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

0 - Optional  FK  value  (weak,  diamond) 


(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


CHILD  END  OF  RELATIONSHIP 


(dot) 


Figure  13.  System  subject  area  tables,  fields,  and  relationships. 


Additionally,  individual  Systems  can  be  identified  as  paid  of  a  larger  System  (a  super  System)  through 
the  hierarchical  association  of  a  ParentSystem_ID  value  in  tdxSystem  with  a  different  System  record  (a  self¬ 
join).  Thus,  a  public-supply  network  could  have  a  System  name  and  consist  of  two  or  more  named  Sub- 
Systems.  Care  should  be  exercised  in  developing  super  Systems  because  individual  Sites  may  be  present  in 
more  than  one  subsystem  (shared  Sites);  duplicates  should  be  resolved  when  handling  Systems  made  up  of 
other  Systems. 

Not  all  aggregates  of  Sites  need  to  be  created  as  named  Systems.  With  the  use  of  domains  and  other 
fields  in  Site -related  tables,  any  number  of  useful  sets  of  Sites  that  meet  specific  criteria  can  be  assembled, 
such  as  those  related  to  UseType,  Location  (geopolitical  and  hydrologic).  Resource  properties.  Conveyance 
actions,  and  Transfer  properties.  The  use  of  the  System  tables  is  reserved  for  custom,  user-defined  aggre¬ 
gates  of  Sites  that  are  identifiable  by  a  convenient  name  and  that  need  to  be  manipulated  as  a  group. 


Address  Subject  Area 

The  Address  subject  area  focuses  on  the  tblAddress  table  and  its  related  entities.  The  Address  subject 
area  diagram  is  shown  in  figure  14.  The  tblAddress  table  provides  a  single  place  to  store  Address  informa¬ 
tion  for  Sites  and  Owners  in  NJWaTr.  Each  Address  record  has  postal  fields  and  is  classified  by  a  selection 
from  the  tdsAddressType  domain.  The  tdsAddressType  domain  currently  contains  three  values  to  accommo¬ 
date  the  types  of  Addresses  anticipated:  "Street,”  “Mailing,”  and  “Street  and  Mailing.”  One  or  more  types 
of  Addresses  for  each  Site  or  Owner  can  be  stored  by  pairing  an  Address  of  a  defined  type  with  a  Site  or 
Owner  using  the  tasSiteAddress  and  tasOwnerAddress  association  tables.  Storing  Address  information  in 
this  way  provides  data-storage  efficiency  for  the  database.  Because  only  Addresses  that  are  known  arc 
stored,  different  types  of  Addresses  can  be  associated  with  single  Sites  or  Owners;  individual  Addresses  can 
serve  more  than  one  Site  and  Owner  as  appropriate  (sharing  an  Address_ID)\  and  fields  for  storing  this 
optional  information  arc  not  needed  in  the  tblSite  or  tblOwner  tables  themselves. 


DataSource  Subject  Area 

The  DataSource  subject  area  focuses  on  the  tdxDataSource  domain  table  and  its  related  entities.  The 
DataSource  subject  area  diagram  is  shown  in  figure  15.  The  tdxDataSource  table  is  a  user-extended  domain 
and  provides  NJWaTr  with  a  single  place  to  store  information  about  the  original  source  of  infomation  for 
records  in  various  entities.  Each  DataSource  has  an  Owner  ( Owner_ID  is  a  FK)  and  a  DataSource  text  de¬ 
scriptor  field.  Because  a  DataSource  has  an  Owner,  some  records  in  the  tblOwner  table  may  be  entered  only 
to  support  a  DataSource  and  not  for  association  with  Sites  or  Conveyances.  The  DataSourceMemo  field  is 
provided  in  tdxDataSource  for  optional  notes  about  each  DataSource.  DataSource  is  a  mandatory  FK 
( DataSource_ID )  that  identifies  the  original  source  of  data  stored  for  Site  and  Resource  User-Defined 
Details  (in  the  tadSiteDetail  and  tadResourceDetail  tables,  respectively),  for  Permit  and  Alias  Labels 
(; tdxPermitLabel  and  tdxAliasLabel,  respectively),  and  for  Transfer/Volumes  ( tblVolume ).  The 
tdxDataSource  table  can  be  used  to  identify  and  retrieve  records  that  arc  associated  with  a  particular  Data¬ 
Source  or  its  parent  Owner. 


Permit  Subject  Area 

The  Permit  subject  area  focuses  on  the  tblPermit  table  and  its  related  entities.  The  Permit  subject  area 
diagram,  shown  in  figure  16,  illustrates  that  the  generic  tblPermit  table  is  linked  through  associative  entities 
to  Sites  and  Owners.  The  identification  of  Sites  and  Owners  by  their  agency-supplied  Permit  codes  was  a 
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tdsAddressType 

AddressTypeJD:  Integer 
AddressType:  Text(20) 


tbIAddress 


AddressJD:  AutoNumber 


AddressTypeJD:  Integer  (FK) 
AddressLinel :  Text(50) 
AddressLine2:  Text(50) 

City:  Text(50) 

StateAbbrv:  Text(2) 

ZipCode:  Text(10) 
CountryAbbrv:  Text(3) 
AddressMemo:  Memo 


tasSiteAddress 


SiteJD:  Long  Integer  (FK) 
AddressJD:  Long  Integer  (FK)  I®- 


tasOwnerAddress 


OwnerJD:  Long  Integer  (FK) 
AddressJD:  Long  Integer  (FK) 


tbISite  tbIOwner 


SiteJD:  AutoNumber 

r 

OwnerJD:  AutoNumber 

Location  ID:  Long  Integer  (FK) 

i 

OwnerType  ID:  Integer  (FK) 

OwnerJD:  Long  Integer  (FK) 

• - j 

OwnerName:  Text(200) 

SiteTypeJD:  Integer  (FK) 

OwnerContact:  Text(200) 

UseTypeJD:  Integer  (FK) 

OwnerPhone:  Text(25) 

SiteName:  Text(IOO) 

OwnerMemo:  Memo 

SiteContact:  Memo 

ParentOwner  ID:  Long  Integer  (FK) 

• 

SiteMemo:  Memo 

1 

Functional  Table  Types 


tbl _ 

BASIC  DATA  TABLE;  tbl  prefix;  yellow 


DOMAIN,  STATIC;  tds  prefix;  blue 


tas _ 

ASSOCIATION,  SIMPLE;  tas  prefix;  white 


EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

- - Mandatory  FK  value  (weak,  no  symbol) 

0 - Optional  FK  value  (weak,  diamond) 


(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


—  CHILD  END  OF  RELATIONSHIP  (dot) 


Figure  14.  Address  subject  area  tables,  fields,  and  relationships. 


41 


tdxDataSource 


tbIOwner 


Owner  ID:  AutoNumber 


OwnerTypeJD:  Integer  NOT  NULL  (FK) 
OwnerName:  Text(200)  NOT  NULL 
OwnerContact:  Text(200) 

OwnerPhone:  Text(25) 

OwnerMemo:  Memo 
ParentOwner  ID:  Long  Integer  (FK) 


FO 


tbIVolume 


DataSource  ID:  AutoNumber 


Owner  ID:  Long  Integer  NOT  NULL  (FK) 
DataSource:  Text(75)  NOT  NULL 
DataSourceMemo:  Memo 


tadSiteDetail 


r, 


SiteJD:  Long  Integer  NOT  NULL  (FK) 
SiteDetailLabelJD:  Long  Integer  NOT  NULL  (FK) 
SiteDetailEffectiveDate:  Date/Time  NOT  NULL 


SiteDetailEndingDate:  Date/Time 
DataSourceJD:  Long  Integer  NOT  NULL  (FK) 
TimelntervalJD:  Integer  NOT  NULL  (FK) 
SiteDetailValue:  Text(50)  NOT  NULL 
SiteDetailMemo:  Memo 


tadResourceDetail 


ResourceJD:  Long  Integer  NOT  NULL  (FK) 
ResourceDetailLabelJD:  Long  Integer  NOT  NULL  (FK) 
ResourceDetailEffectiveDate:  Date/Time  NOT  NULL 

ResouroeDetailEndingDate:  Date/Time 
DataSourceJD:  Long  Integer  NOT  NULL  (FK) 
ResourceDetail:  Text(50)  NOT  NULL 
ResourceDetailMemo:  Memo 


VolumeJD:  AutoNumber 


Transfer  ID:  Long  Integer  NOT  NULL  (FK) 

Staff _ I D :  Long  Integer  NOT  NULL  (FK) 

DataSourceJD:  Long  Integer  NOT  NULL  (FK) 
VolumeMethodJD:  Long  Integer  NOT  NULL  (FK) 
RawVolumeValue:  Double  NOT  NULL 
VolumeUnitJD:  Long  Integer  NOT  NULL  (FK) 
IsDefauItVolume:  Yes/No  NOT  NULL 
VolumeMemo:  Memo 


tdxAliasLabel 

AliasLabelJD:  AutoNumber 


DataSourceJD:  Long  Integer  NOT  NULL  (FK) 
AliasSource:  Text(75) 

Alias  Label:  Text(50)  NOT  NULL 
AliasLabelMemo:  Memo 


tdxPermitLabel 


PermitLabelJD:  AutoNumber 


DataSourceJD:  Long  Integer  NOT  NULL  (FK) 
PermitLabel:  Text(50)  NOT  NULL 
PermitLabelMemo:  Memo 


Functional  Table  Types 


tbl _ 

BASIC  DATA  TABLE;  tbl  prefix;  yellow 


DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 


tad 


ASSOCIATION,  WITH  DATA;  tad  prefix;  green 


EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

-  Mandatory  FK  value  (weak,  no  symbol) 

0— - Optional  FK  value  (weak,  diamond) 


(20)  numbers  in  parentheses 

INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


—  CHILD  END  OF  RELATIONSHIP  (dot) 


Figure  15.  DataSource  subject  area  tables,  fields,  and  relationships. 
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tasSitePermit 


SiteJD:  Long  Integer  (FK) 
PermitJD:  Long  Integer  (FK) 


tbISite 

SiteJD:  AutoNumber 


LocationlD:  Long  Integer  (FK) 
Owner  ID:  Long  Integer  (FK) 
SiteTypeJD:  Integer  (FK) 
UseTypeJD:  Integer  (FK) 
SiteName:  Text(IOO) 
SiteContact:  Memo 
SiteMemo:  Memo 


tbl  Permit 


PermitJD:  AutoNumber 

PermitLabelJD:  Long  Integer  (FK)  *7 
PermitSeriesJD:  Integer  (FK) 
PermitNumber:  Text(50) 

PermitMemo:  Memo 


tdsPermitSeries 

PermitSeriesJD:  Integer 

PermitSeries:  Text(50) 
PermitSeriesDescription:  Text(IOO) 


tasOwnerPermit 


tdxPermitLabel 


Owner  lD:  Long  Integer  (FK) 
PermitJD:  Long  Integer  (FK) 


PermitLabelJD:  AutoNumber 

DataSourceJD:  Long  Integer  (FK) 
PermitLabel:  Text(50) 
PermitLabelMemo:  Memo 


tdxDataSource 


DataSourceJD:  AutoNumber 

Owner  ID:  Long  Integer  (FK) 
DataSource:  Text(75) 
DataSourceMemo:  Memo 


L  _  . 

r  —  - 


tbIOwner 


Owner  ID:  AutoNumber 

OwnerTypeJD:  Integer  (FK) 
OwnerName:  Text(200) 
OwnerContact:  Text(200) 
OwnerPhone:  Text(25) 
OwnerMemo:  Memo 
ParentOwner  ID:  Long  Integer  (FK) 


1 


Functional  Table  Types 


tbl 


BASIC  DATA  TABLE;  tbl  prefix;  yellow 

DOMAIN,  STATIC;  tds  prefix;  blue 


tdx _ 

DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 

tas 

ASSOCIATION,  SIMPLE;  tas  prefix;  white 


EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK)  (FK) 


PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

■ - Mandatory  FK  value  (weak,  no  symbol) 

0 - Optional  FK  value  (weak,  diamond) 


(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


-  —  CHILD  END  OF  RELATIONSHIP  (dot) 


Figure  16.  Permit  subject  area  tables,  fields,  and  relationships. 


high-priority  requirement  for  the  database.  Permits  for  Sites,  for  example,  allow  Site  information  to  be 
displayed  and  reported  using  alternative  state.  Federal,  or  local  regulatory  codes  familial-  to  users.  In 
addition.  Permit  codes  can  be  useful  during  batch  loading  of  data  through  a  data-entry  application. 

Permit  storage  and  identification  in  NJWaTr  is  implemented  after  the  fashion  of  Aliases  in  the 
NEWUDS  model;  Aliases  also  are  present  in  the  NJWaTr  model  and  will  be  discussed  separately.  A  single 
tblPermit  table  serves  the  Permit  storage  and  identification  function  for  all  entities.  This  approach  offers  the 
advantage  of  having  no  Null  values  in  any  field  used  for  Permit  assignment,  keeping  the  number  of  tables 
and  fields  involved  in  Permit  assignment  and  identification  to  a  minimum,  and  allowing  any  number  of 
Permits  for  any  number  of  entities  to  be  implemented  using  the  same  structure.  Because  the  tblPermit  table 
only  contains  Permits  that  are  puiposely  defined.  Sites  and  Owners  that  do  not  have  or  need  a  Permit  assign¬ 
ment  do  not  have  a  record  in  that  table. 

The  Permit  structure  works  by  keeping  all  Permit  values  (the  assigned  name  or  code)  in  one  table 
along  with  a  label  selection  from  the  tdxPermitLabel  domain,  which  includes  the  source  of  the  Permit  (Data- 
Source  whose  Permit  code  is  being  applied).  Sites  and  Owners  are  linked  to  the  tblPermit  table  through 
association  tables,  where  an  individual  entity  instance  is  paired  with  an  individual  Permit.  The  association 
tables  provide  a  rapid  method  for  checking  to  see  whether  a  Permit  exists  for  a  given  item  (by  searching  for 
the  item’s  _ID  value),  whereas  the  tdxPermitLabel  table  allows  filtering  for  Permits  from  a  specific  Data- 
Source  or  for  kinds  of  Permits  that  are  assigned  a  specific  PermitLabel  value. 

In  the  table  tblPermit,  each  Permit  is  identified  by  a  unique  Permit _ID.  Each  Permit  is  defined  by  a 
standardized  set  of  attributes:  a  PermitSeries,  PermitLabel,  and  PermitNumber.  The  PermitSeries  is  a 
selection  from  a  static  domain,  tdsPermitSeries,  that  stores  a  list  of  water  allocation,  safe  drinking-water, 
and  New  Jersey  Pollutant  Discharge  Elimination  System  (NJPDES)  permit  series  codes  used  to  group  Sites 
in  New  Jersey  (Hoffman  and  Lieberman,  2000).  A  PermitMemo  field  is  included  for  recording  optional 
notes  about  individual  Permits  when  necessary.  The  PermitLabel  is  supplied  by  the  tdxPermitLabel  domain 
table,  which  also  holds  a  FK  link  to  the  tdxDataSource  domain.  The  tdxPermitLabel  table  also  includes  a 
memo  field,  PermitLabelMemo,  to  record  optional  descriptions  of  abbreviated  labels  or  to  provide  explana¬ 
tions  for  a  label. 

Association  tables  are  used  to  link  a  Permit  to  other  tables  that  need  Permit  assignment.  Thus, 
tasSitePermit  links  a  Site_ID  to  a  Permit _ID,  and  tas Owner Permit  links  an  Owner_ID  to  a  Permit_ID.  Ad¬ 
ditional  associations  could  be  added  later  for  other  entities  that  are  not  currently  provided  with  Permit  as¬ 
signments.  Each  Permit  record  will  typically  serve  a  single  associate  but  can  apply  to  more  than  one  if  that 
is  a  valid  assignment,  and  the  Permit  is  not  limited  to  any  one  entity  type  because  it  does  not  store  any 
associate  information  directly  (the  linkage  is  handled  in  the  tas  association  tables).  Single  items  also  can 
have  as  many  Permits  as  needed. 

A  hypothetical  example  of  defining  a  Permit  in  NJWaTr  can  be  illustrated  with  an  Owner’s  agricul¬ 
tural  withdrawal  Permit.  A  permit  is  issued  to  farmer  John  Smith  for  surface-water  withdrawals  of  more 
than  100,000  gallons  per  day  to  serve  his  large  cranberry  farm  operation.  The  permit  is  issued  by  the  Bureau 
of  Water  Allocation  (BWA)  of  the  NJDEP.  Farmer  Smith's  permit  designation  is  “BWA  XYZ0001.”  In 
NJWaTr,  the  Owner _ID  for  “Smith,  John”  would  be  connected  to  the  associated  Permit  (as  Permit _ID) 
through  the  tas  Owner  Permit  table.  Appropriate  field  values  for  defining  the  Permit  could  be  as  follows: 

Owner  in  tblOwner  =  “Smith,  John”  (for  an  Owner  Permit,  the  Owner  here  is  the  person/organization  to 
whom  the  permit  is  issued), 

DataSource  in  tdxDataSource  =  “Bureau  of  Water  Allocation”  (issues  the  allocation  permit;  the  Owner  of 
the  DataSource  is  the  NJDEP), 
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PermitLabel  in  tdxPermitLabel  =  “BWA”  (label  for  a  BWA  permit), 

PermitNumber  in  tblPermit  =  “XYZ0001”  (uniquely  identifies  John  Smith’s  BWA  permit),  and 

PermitSeries  in  tdsPermitSeries  -  “Agricultural  certifications”  (surface-  and  ground-water  withdrawals  for 
agricultural  use  >  100,000  gallons  per  day). 


Using  this  example,  if  all  BWA  Permits  used  the  same  PermitLabel  value,  it  would  be  possible  to 
construct  a  query  to  find  all  BWA-Permitted  Owners  or  to  locate  an  individual  Owner  if  the  Permit  number 
was  known. 

Permits  can  be  retrieved  as  a  group  on  the  basis  of  the  source  or  label  to  supply  a  different  name  field 
to  the  associated  entity.  For  example,  the  Permit  structure  and  data  can  be  manipulated  through  a  query  to 
automatically  create  fields  for  each  label  for  each  Permitted  entity.  An  example  of  using  a  crosstab  query  to 
link  Permits  directly  to  the  Owner  table  as  extended  attributes  is  given  in  the  section  “Construction  and  Use 
of  Views.” 

Using  the  DataSource  and  PermitLabel  fields  judiciously,  it  is  possible  to  store  and  retrieve  an 
unlimited  number  of  regulatory  coding  schemes  (by  agency  or  department)  and  use  them  in  place  of  the 
formal  names  given  in  the  associated  entities.  This  is  much  more  powerful  than  setting  up  separate  fields 
for  specific  coding  schemes.  It  is  expected  that  over  time,  however,  examination  of  the  tblPermit  table  will 
indicate  which  Permits  arc  truly  needed  as  fields  within  the  Site  and  Owner  entities  and  that  the  tblPermit 
table  then  can  be  used  to  transfer  values  from  those  fields  to  the  other  tables  directly,  such  as  making  a  BWA 
field  in  the  tblSite  table  to  hold  Site-specific  BWA  permit  numbers. 

One  more  advantage  of  storing  Permits  is  that  the  codes  stored  could  be  used  to  link  to  other  databas¬ 
es.  In  the  discharge  Permit  example  above,  because  the  PermitNumber  “XYZ0001”  would  be  the  same  iden¬ 
tification  used  in  the  NJDEP  BWA  database,  comparisons  of  information,  retrievals,  and  imports  from  other 
databases  made  using  the  Permit  code  would  be  facilitated. 


Alias  Subject  Area 

The  Alias  subject  area  focuses  on  the  tblAlias  table  and  its  related  entities.  The  Alias  subject  area 
diagram,  shown  in  figure  17,  illustrates  that  the  generic  tblAlias  table  is  linked  through  associative  entities 
to  Sites,  Resources,  and  Conveyances.  Aliases  arc  distinct  from  Permits  in  that  a  Permit  code  is  an  officially 
assigned  regulatory  identifier,  whereas  an  Alias  represents  all  other  alternative  naming  schemes  (such  as  a 
local  name).  Aliases  for  Sites,  for  example,  would  allow  Site  information  to  be  displayed  and  reported  using 
alternative  state.  Federal,  or  local  names  familial-  to  users  or  by  their  unique  identifiers  found  in  other  data¬ 
bases.  Aliases,  like  Permit  numbers,  also  can  be  useful  during  batch  loading  of  data  through  a  data-entry 
application. 

Initially,  some  Alias  codes  were  created  using  separate  fields  within  entities  bearing  the  name  of  the 
alias  scheme.  The  current  system  uses  a  single  tblAlias  table  to  serve  the  alias  function  for  all  entities.  The 
same  advantages  as  with  the  Permit  entity  apply:  no  Null  values  are  allowed  in  any  field  used  for  alternative 
naming  schemes;  the  number  of  tables  and  fields  involved  in  providing  complete  alias  services  are  kept  to 
a  minimum;  and  any  number  of  naming  schemes  for  any  number  of  entities  are  implemented  using  the  same 
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tbIAIias 

AliasJD:  AutoNumber 


-1^ 

Ox 


AliasLabelJD:  Long  Integer  (FK) 
AliasValue:  Text(50) 

AliasMemo:  Memo 


tdxAliasLabel 


—  AliasLabel  ID:  AutoNumber 


DataSource_ID:  Long  Integer  (FK) 
AliasSource:  Text(75) 

AliasLabel:  Text(50) 
AliasLabelMemo:  Memo 


tdxDataSource 

DataSource  ID:  AutoNumber 


OwnerJD:  Long  Integer  (FK) 
DataSource:  Text(75) 
DataSourceMemo:  Memo 


tasSiteAlias 


tasResourceAIias 

FiesourceJD:  Long  Integer  (FK) 
AliasJD:  Long  Integer  (FK) 


tbISite 


tbIResource 


ResourceJD:  AutoNumber 

WaterBodyTypeJD:  Integer  (FK) 
OwnerJD:  Long  Integer  (FK) 
ResourceName:  Text(200) 
ResourceCodeName:  Text(200) 
ResourceMemo:  Memo 


tasConveyanceAlias 


ConveyanceJD:  Long  Integer  (FK) 
AliasJD:  Long  Integer  (FK) 


v 


tbIConveyance 

ConveyanceJD:  AutoNumber 

ConveyanceTypeJD:  Integer  (FK) 
ConveyanceActionJD:  Integer  (FK) 
ConveyanceName:  Text(200) 
ConveyanceMemo:  Memo 


Functional  Table  Types 


tbl 


tdx 


tas 


BASIC  DATA  TABLE;  tbl  prefix;  yellow 


DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 


ASSOCIATION,  SIMPLE;  tas  prefix;  white 


EXPLANATION 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

PK 

field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 

the  PK) 

(FK) 

PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 

FOREIGN  KEY  FIELD 


STRONG  RELATIONSHIP 
WEAK  RELATIONSHIP 
PARENT  END  OF  RELATIONSHIP 

Mandatory  FK  value  (strong,  no  symbol) 
Mandatory  FK  value  (weak,  no  symbol) 


(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


—  CHILD  END  OF  RELATIONSHIP  (dot) 


Figure  17.  Alias  subject  area  tables,  fields,  and  relationships. 


structure.  Because  the  tblAlias  table  contains  only  Aliases  that  are  puiposely  defined.  Sites,  Resources,  and 
Conveyances  that  do  not  have  or  need  an  Alias  do  not  have  a  record  in  that  table. 

The  Alias  structure  works  by  keeping  all  Alias  values  (the  alternative  name  or  code)  in  one  table, 
along  with  a  label  selection  from  the  tdxAliasLabel  domain  which  includes  the  source  of  the  Alias  (whose 
naming  scheme  is  being  used).  Each  entity  that  requires  alias  services  is  linked  to  the  tblAlias  table  through 
an  association  table,  where  an  individual  entity  record  is  paired  with  an  individual  Alias.  The  association 
table  provides  a  rapid  method  for  checking  to  see  whether  an  Alias  exists  for  a  given  item  (by  searching  for 
the  item’ s  _ID  value),  whereas  the  tdxAliasLabel  table  allows  filtering  for  Aliases  from  a  specific  Data- 
Source  or  assigned  a  specific  AliasLabel. 

In  the  table  tblAlias,  each  Alias  is  identified  by  a  unique  Alias_ID.  Each  Alias  is  defined  by  a  stan¬ 
dardized  set  of  attributes:  an  AliasValue,  AliasLabel,  and  AliasSource.  An  AliasMemo  field  is  included  for 
recording  optional  notes  about  individual  Aliases  when  necessary.  The  AliasLabel  and  AliasSource  arc 
supplied  by  the  tdxAliasLabel  domain  table,  which  also  holds  a  link  to  the  tdxDataSource  domain.  The 
tdxAliasLabel  table  also  includes  a  memo  field,  AliasLabelMemo,  to  record  optional  descriptions  of  abbre¬ 
viated  labels  or  to  provide  explanations  for  a  label. 

Association  tables  are  used  to  link  an  Alias  to  other  tables  that  need  Alias  assignment.  Thus, 
tasSiteAlias  links  a  Site_ID  to  an  Alias_ID;  tasRe  source  Alias  links  a  Resource_ID  to  an  Alias _ID\  and 
tasConveyanceAlias  links  a  Conveyance_ID  to  an  Alias_ID.  Additional  associations  could  be  added  later 
for  other  entities  that  are  not  currently  provided  with  alias  services.  Each  Alias  record  will  typically  serve  a 
single  associate  but  can  apply  to  more  than  one.  An  Alias  record  is  not  limited  to  any  one  entity  type  because 
it  does  not  store  any  associate  information  directly  (the  linkage  is  handled  in  the  tas  association  tables). 
Single  items  also  can  have  as  many  Aliases  as  needed. 

Aliases  can  be  retrieved  as  a  group  on  the  basis  of  the  source  or  label  to  supply  a  different  name  field 
to  the  associated  entity.  For  example,  the  Alias  structure  and  data  can  be  manipulated  through  a  query  to 
automatically  create  fields  for  each  label  for  each  entity  associated  with  an  Alias.  The  example  of  using  a 
crosstab  query  to  link  Permit  numbers  directly  to  the  Owner  table  as  extended  attributes  given  in  the  section, 
“Construction  and  Use  of  Views,”  also  is  applicable  to  Aliases. 

Using  the  AliasSource  and  AliasLabel  fields  judiciously,  it  is  possible  to  store  and  retrieve  an 
unlimited  number  of  alternative  coding  systems  (by  agency,  office,  or  individual)  and  use  them  in  place  of 
the  formal  names  given  in  the  associated  entities.  This  is  much  more  powerful  than  setting  up  separate  fields 
for  specific  coding  schemes.  It  is  expected  that  over  time,  however,  examination  of  the  tblAlias  table  will 
indicate  which  Aliases  arc  truly  needed  as  fields  within  the  tblSite,  tblConveyance,  and  tblResource  data 
tables.  The  tblAlias  table  then  can  be  used  to  transfer  values  from  those  fields  to  the  other  tables  directly. 


User-Defined  Details 

The  User-Defined  Details  subject  area  describes  the  entity  and  relationship  components  that  serve  the 
unknown  attribute  storage  needs  of  several  entities.  The  User-Defined  Details  subject  area  diagram  is  shown 
in  figure  18.  Several  specific,  optional  attributes  of  various  entities  in  the  database  were  added  as  fields 
during  the  development  of  NJWaTr  and  later  removed.  Some  of  these  fields  became  domains,  whereas 
others  were  removed  because  it  was  determined  that  they  applied  only  to  a  small  subset  of  the  table’s  records 
or  would  be  used  infrequently.  A  general  method  was  needed  to  store  specific  kinds  of  information  that  arc 
either  optional  or  not  known  in  advance  and  that  could  not  be  designed  directly  into  the  table  structures.  The 
strategy  for  storing  such  data  resulted  in  User-Defined  Detail  structures  in  NJWaTr. 
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tadSiteDetail 


00 


tbISite 

SiteJD:  AutoNumber 


Location_ID:  Long  Integer  (FK) 
Owner _ID:  Long  Integer  (FK) 
SiteTypeJD:  Integer  (FK) 
UseTypeJD:  Integer  (FK) 
SiteName:  Text(IOO) 
SiteContact:  Memo 
SiteMemo:  Memo 


tbIResource _ 

ResourceJD:  AutoNumber 


WaterBodyTypeJD:  Integer  (FK) 
Owner _ID:  Long  Integer  (FK) 
ResourceName:  Text(200) 
ResourceCodeName:  Text(200) 
ResourceMemo:  Memo 


tbIVolume 

VolumeJD:  AutoNumber 

TransferJD:  Long  Integer  (FK) 
StaffJD:  Long  Integer  (FK) 
DataSource_ID:  Long  Integer  (FK) 
VolumeMethodJD:  Long  Integer  (FK) 
RawVolumeValue:  Double 
VolumeUnitJD:  Long  Integer  (FK) 
IsDefauItVolume:  Yes/No 
VolumeMemo:  Memo 


SiteJD:  Long  Integer  (FK) 
SiteDetailLabelJD:  Long  Integer  (FK) 
SiteDetailEffectiveDate:  Date/Time 


SiteDetailEndingDate:  Date/Time 
DataSourceJD:  Long  Integer  (FK) 
TimelntervalJD:  Integer  (FK) 
SiteDetailValue:  Text(50) 
SiteDetailMemo:  Memo 


tdxSiteDetailLabel 

-  SiteDetailLabelJD:  AutoNumber 

SiteDetailCategoryJD:  Long  Integer  (FK) 
SiteDetailLabel:  Text(50) 

IsNumericDetail:  Yes/No 
“I  SiteDetailUnit:  Text(50) 

SiteDetailLabelMemo:  Memo 


tdsTimelnterval 

-  TimelntervalJD:  Integer 
Timelnterval:  Text(25) 


tadResourceDetail 


ResourceJD:  Long  Integer  (FK) 
ResourceDetailLabelJD:  Long  Integer  (FK) 
ResourceDetailEffectiveDate:  Date/Time 

ResourceDetailEndingDate:  Date/Time 
DataSourceJD:  Long  Integer  (FK) 
ResourceDetail:  Text(50) 
ResourceDetailMemo:  Memo 


L  . 


tadVolumeDetail 


VolumeJD:  Long  Integer  (FK) 
VolumeDetailLabelJD:  Long  Integer  (FK)  •  - 

VolumeDetail:  Text(50) 

VolumeDetailMemo:  Memo 


tdxResourceDetailLabel 

-  ResourceDetailLabelJD:  AutoNumber 

ResourceDetailLabel:  Text(50) 
ResourceDetailLabelMemo:  Memo 


tdxVolumeDetailLabel 

.  VolumeDetailLabelJD:  AutoNumber 

VolumeDetailLabel:  Text(50) 
VolumeDetailLabelMemo:  Memo 


tdxSiteDetailCategory 

SiteDetailCategoryJD:  AutoNumber 
SiteDetailCategory:  Text(50) 


tdxDataSource 

DataSource_ID:  AutoNumber 
OwnerJD:  Long  Integer  (FK) 
DataSource:  Text(75) 
DataSourceMemo:  Memo 


tbIConveyance 

ConveyanceJD:  AutoNumber 

ConveyanceTypeJD:  Integer  (FK) 
ConveyanceActionJD:  Integer  (FK) 
ConveyanceName:  Text(200) 
ConveyanceMemo:  Memo 


tadConveyanceDetail 

(g - - - 

ConveyanceJD:  Long  Integer  (FK) 
ConveyanceDetailLabelJD:  Long  Integer  (FK) 

ConveyanceDetail:  Text(50) 
ConveyanceDetailMemo:  Memo 


tdxConveyanceDetailLabel 


ConveyanceDetailLabel  ID:  AutoNumber 

ConveyanceDetailLabel:  Text(50) 
ConveyanceDetailLabelMemo:  Memo 

EXPLANATION 


Functional  Table  Types 


Table  and  Relationship  Symbols 


Field  Property  Indicators 


tbl _ 

BASIC  DATA  TABLE;  tbl  prefix;  yellow 


tds 

DOMAIN,  STATIC;  tds  prefix;  blue 


tdx _ 

DOMAIN,  USER-EXTENDABLE;  tdx  prefix;  gray 

tad 

ASSOCIATION,  WITH  DATA;  tad  prefix;  green 


~1  INDEPENDENT  TABLE  (no  foriegn  key  [FK] 

I - 1  field  in  the  primary  key  [PK]) 

DEPENDENT  TABLE  (at  least  one  FK  field  in 
_  the  PK) 

-  STRONG  RELATIONSHIP 

- WEAK  RELATIONSHIP 

PARENT  END  OF  RELATIONSHIP 

-  Mandatory  FK  value  (strong,  no  symbol) 

- Mandatory  FK  value  (weak,  no  symbol) 

-  —  CHILD  END  OF  RELATIONSHIP  (dot) 


PRIMARY  KEY  (PK)  FIELDS  ABOVE  LINE 
NON-PK  FIELDS  BELOW  LINE 


(FK)  FOREIGN  KEY  FIELD 

(20)  NUMBERS  IN  PARENTHESES 
INDICATE  TEXT  FIELD 
MAXIMUM  NUMBER  OF 
CHARACTERS 


Figure  18.  User-Defined  Detail  subject  area  tables,  fields,  and  relationships. 


A  User-Defined  Detail  structure  uses  a  tad  associative  entity  to  join  a  specific  instance  of  a  core 
element  with  a  label  that  describes  some  detail  about  it  and  stores  the  detail  value  using  that  label.  Thus, 
labels  can  be  created  as  needed  for  particular  detail  value  types  and  reused  for  other  associates.  As  with 
Alias  labels,  careful  consideration  and  occasional  reevaluation  of  the  detail  labels  can  provide  a  mechanism 
for  retrieving  sets  of  similar  types  of  information  and  for  refining  searches  and  aggregations  of  data  in 
controlled  ways.  NJWaTr  contains  User-Defined  Detail  structures  for  Sites,  Conveyances,  Volumes,  and 
Resources. 

Many  details  about  the  various  types  of  Sites  in  the  NJWaTr  database  can  be  tracked.  Site  User- 
Defined  Details  can  include  label  values  such  as  “Population  served”  for  public-supply  distribution  systems 
or  wastewater-collection  systems,  “Status”  to  store  the  operational  status  of  a  well  or  treatment  plant, 
“Employees”  to  store  the  number  of  employees  at  an  industrial  facility,  “Kilowatts  generated”  to  store  the 
power  provided  by  a  nuclear  facility,  or  “Cost”  to  store  the  amount  charged  for  water  by  a  purveyor. 

User-Defined  Details  about  Sites  can  change  over  time,  and  temporal  fields  arc  needed  to  define  the 
periods  of  time  covered  by  the  detail  values  stored.  The  tadSiteDetail  table  associates  a  specific  Site_ID  with 
a  specific  SiteDetailLabel_ID  and  a  specific  SiteDetailEJfectiveDate  to  form  its  PK.  This  complex  PK 
allows  the  same  detail  Label  to  apply  to  a  Site  for  different  non-overlapping  periods  of  time,  thus  allowing 
changes  in  detail  values  to  be  tracked  over  time  (for  example,  the  population  served  by  a  wastewater- 
collection  operation).  The  non-PK  fields  in  tadSiteDetad  are  the  SiteDetailEndingDate  (if  known),  the 
SiteDetailValue  itself,  a  SiteDetailMemo  for  optional  notes  about  the  detail  value,  and  through  FKs,  the 
detail  DataSource  and  Timelnterval  classification  to  which  the  detail  applies. 

The  tdxSiteDetadLabel  domain  is  nested  within  the  tdxSiteDetailCategory  domain  for  general  detail- 
label  classification  information.  The  tdxSiteDetadLabel  domain  includes  a  label  field,  a  unit  field,  and  a 
memo  field  for  notes.  A  field  named  IsNumericDetail  is  used  to  identify  SiteDetailLabek  associated  with 
any  SiteDetailValue  that  can  be  converted  to  a  numeric  data  type  for  use  in  mathematical  manipulations  (for 
example,  the  number  of  employees  at  industrial  Sites). 

Resource  User-Defined  Details  ( tadResourceDetail )  are  similar  to  Site  Details  in  that  they  arc  date- 
bounded  and  have  a  DataSource  associated  with  them.  Examples  of  details  that  could  be  stored  for  a 
Resource  arc  depth  or  acreage  of  a  reservoir  and  fisheries  classification  information. 

User-Defined  Details  about  Transfer  Volumes  (tadVol urn e D e tail)  have  a  DataSource  but  arc  not 
date-bounded.  The  structure  initially  was  provided  to  allow  a  mechanism  to  store  information  on  accuracy 
until  a  more  suitable  method  was  identified.  In  that  case,  “Accuracy”  would  be  a  VolumeDetailLabel  value, 
and  the  accuracy  to  be  associated  with  a  particular  RawVolumeValue  would  be  entered  as  the  VolumeDetail 
value.  Other  labels  can  be  developed  as  needed. 

User-Defined  Details  for  a  Conveyance  ( tadConveyanceDetail )  are  not  date-bounded  and  do  not  have 
a  DataSource.  Conveyance  details  could  include  construction  date,  material,  capacity,  and  head  type 
(pumped  or  gravity  fed). 


OPERATIONAL  ISSUES  AND  PROCEDURES 

The  use  of  NJWaTr  for  water-use  data  requires  an  understanding  of  the  basic  data  model,  details  of 
the  data  elements,  and  the  operational  aspects  of  working  with  data  in  that  specific  model  design.  Opera¬ 
tional  considerations  include  (1)  creation  of  indexes  in  an  individual  implementation  of  the  MS  Access 
database;  (2)  restrictions  on  table  loading  order  due  to  table  dependencies  and  data  protection  settings,  such 
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as  forcing  selection  of  classification  terms  from  domain  tables;  (3)  automatic  updating  of  fields  from  other 
data  to  facilitate  uniformity;  and  (4)  simplification  of  multi-table  structures  for  handling  and  presenting  data. 
Several  operational  strategics  have  been  developed  using  queries  that  are  stored  in  the  NJWaTr  database  as 
named  Structured  Query  Language  (SQL)  statements. 


Indexes 

An  index  is  a  separate  physical  object  within  a  relational  database.  It  stores  a  sorted  list  of  values  from 
one  or  a  combination  of  fields  with  pointers  to  individual  data  records  that  contain  those  values.  An  index 
is  used  by  a  database  engine  to  rapidly  identify  the  location  of  specific  records  in  tables  by  use  of  the  indexed 
values;  it  can  significantly  increase  performance  when  querying  or  reporting  from  a  database.  A  unique 
index  also  can  be  created  for  one  or  more  fields  to  ensure  the  uniqueness  of  values  as  an  alternate  PK  or  for 
other  puiposes.  Therefore,  management  of  indexes  can  affect  the  operational  efficiency  and  integrity  of  a 
database. 

NJWaTr  is  conservative  in  the  general  use  of  indexes.  Access  automatically  creates  an  index  for  the 
PK  and  any  FK  fields  for  each  table.  The  PK  is  a  special  type  of  unique  index,  and  the  non-unique  index  for 
FK  fields  facilitates  the  joining  of  tables  and  look-up  activity  without  requiring  any  textual  values  that  the 
keys  represent  to  be  sorted  or  indexed.  Because  NJWaTr  follows  the  standard  of  using  information-neutral 
surrogate  key  fields  as  a  table’s  PK,  all  domain  ( ids  and  tdx)  and  basic  data  (tbl)  tables  also  have  been 
equipped  with  one  unique  index  to  help  prevent  inadvertent  duplication  of  data.  For  example,  the  table 
tblOwner  has,  in  addition  to  its  PK  (Owner JD)  and  FK  ( OwnerType_ID )  indexes,  a  unique  index  for  the 
required  OwnerName  field;  the  name  is  protected  by  the  unique  index  and  cannot  be  duplicated  within  the 
table.  Some  unique  indexes  arc  only  partially  enforced  by  design,  such  as  one  for  the  ResourceCodeName 
in  the  tblResource  table;  that  field  is  optional  and  used  primarily  when  there  is  duplication  in  the 
ResourceName  field.  The  ResourceCodeName  index  is  used  to  prevent  duplication  of  entered  values  while 
ignoring  records  where  no  entry  was  made  (a  Null  value).  Associative  entities  have  the  uniqueness  of  each 
record  guaranteed  by  the  structure  of  the  PK  and  do  not  require  alternate  unique  indexes. 

The  unique  indexes  can  be  modified  for  any  implementation  of  NJWaTr,  particularly  if  it  is  deter¬ 
mined  that  an  index  prevents  actual  unique  records  from  being  added.  Such  restrictive  indexes  should  be 
changed  or  removed.  The  creation  of  other  indexes  should  be  considered  for  any  fields  or  combinations  of 
fields  that  could  be  used  for  grouping,  sorting,  or  filtering  NJWaTr  data  because  an  index  can  improve  per¬ 
formance  in  queries  and  reports.  Because  the  identification  of  fields  that  can  benefit  from  an  index  depends 
on  how  the  database  is  used,  creation  of  additional  indexes  arc  left  to  the  individual  implementations  of  the 
database. 


Table  Loading  Order 

Key  structures  affect  table  loading  order.  This  information  is  important  for  hand-entry  of  data  and  for 
providing  structural  logic  when  building  a  batch  loader  or  user-interface  application  for  NJWaTr.  For 
example,  a  tblConveyance  record  should  not  be  established  without  records  for  the  Sites  that  will  form  the 
Conveyance  ends  already  in  the  tblSite  table.  A  tblConveyance  record  then  can  be  added,  followed  by  two 
entries  in  tadSiteConveyance  to  create  the  From  and  To  Site  identities  for  the  Conveyance.  All  static 
(tds  prefix)  and  many  user-extendable  (tdx)  domains  are  already  populated  in  the  standard  NJWaTr 
database.  Basic  data  tables  (tbl)  require  at  least  one  domain  FK,  so  they  cannot  be  loaded  until  the  domain 
is  populated  with  needed  values.  Association  tables  (tas  and  tad)  arc  dependent  on  parent  table  records  by 
definition,  and  throughout  NJWaTr,  the  nesting  of  table  keys  establishes  other  loading  order  requirements. 
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As  a  guide  for  users,  loading  order  information  is  summarized  for  each  of  the  76  NJWaTr  tables  in 

table  1.  This  information  should  be  used  to  establish  proper  data-entry  order  and  conditions.  Columns  in 

table  1  include  the  following: 

Loading  order — a  number  representing  the  position  of  a  table  in  the  overall  loading  order.  All  tables  with 
a  loading  order  of  1  may  be  populated  immediately;  2’s  require  at  least  one  table  at  the  1  level  to  have 
been  populated  with  the  necessary  records;  3’s  require  at  least  one  table  at  level  2  to  have  the  necessary 
records;  and  so  forth.  The  loading  order  is  a  literal  value  that  represents  the  direct  chain  of  incoming 
relational  dependencies,  but  the  loading  notes  also  should  be  consulted  to  determine  the  actual 
sequence  on  the  basis  of  indirect  relationships  through  other  entities; 

Table  name — the  name  of  the  table  in  NJWaTr; 

Incoming  relationships  -  parent  tables — the  number  of  tables  with  defined  relationships  entering  the  current 
table  and,  therefore,  providing  a  FK,  along  with  a  list  of  the  parent  table  names; 

Outgoing  relationships  -  child  tables — the  number  of  tables  that  will  receive  the  PK  of  the  current  table  as 
a  FK  through  a  defined  relationship,  along  with  a  list  of  the  child  table  names;  and 

Note — things  to  consider  before  or  during  the  process  of  adding  records  to  a  table;  where  “Some  fields  are 
optional”  is  noted,  consult  the  data  dictionary  for  details  about  optional  and  required  fields  in  a  table. 


Maintenance  Update  Queries 

Several  queries  arc  provided  in  the  NJWaTr  database  to  perform  data  maintenance  functions  and  to 
facilitate  manipulation  of  the  data  after  it  has  been  entered.  The  queries  to  perform  these  functions  arc  run 
manually  or  can  be  triggered  to  run  automatically  within  an  application  interface  for  NJWaTr.  The  main¬ 
tenance  queries  arc  named  with  the  prefix  qrm  to  distinguish  them  from  other  queries  stored  within  the 
database. 


Volume  Unit  Updates 

The  cluster  of  domain  tables  centered  on  tdxVolumeUnit  (fig.  9)  provide  the  ability  to  create 
VolumeUnit  choices  for  any  possible  combination  of  decimal  and  quantity  components,  as  discussed  in  the 
“Transfer/Volume  Subject  Area”  section  of  this  document.  A  new  VolumeUnit  is  added  to  the  domain  by 
selecting  one  choice  from  each  of  the  two  tables  tdsVolumeUnitDecimal  and  tdsVolumeUnitTime',  an  appro¬ 
priate  standard  VolumeUnit  abbreviation  is  entered  manually  in  the  field  VolumeUnitAbbrv.  Two  remaining 
fields  arc  provided  with  default  values  of  “-1”  when  new  VolumeUnit  entries  arc  added — 
VolumeUnitPhrase  and  MGConversion.  Although  this  process  establishes  the  basics  of  the  new  record  in 
the  tdxVolumeUnit  table,  one  additional  step  is  needed  to  complete  the  description  of  the  unit  in  that  table. 

The  new  record  in  the  tdxVolumeUnit  table  must  be  updated  with  a  standardized  component  phrase 
that  describes  it  in  the  field  VolumeUnitPhrase  (for  example,  “thousand  cubic  feet”),  and  a  conversion  factor 
from  the  new  unit  to  a  MG  equivalent  must  be  determined  and  placed  in  the  field  MGConversion.  The 
default  value  for  both  VolumeUnitPhrase  and  MGConversion  for  newly  created  VolumeUnits  is  “-1.”  The 
“-1”  value  serves  as  a  flag  for  records  that  have  not  yet  been  updated.  Replacing  the  “-1”  flag  with  a  valid 
conversion  value  and  phrase  is  done  using  two  queries.  One  query  sets  things  up  and  the  other  performs  the 
update.  Only  the  second  query  must  be  run. 
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Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) 


Loading 

order 

Table  name 

Incoming  relationships  -  parent  tables 

Outgoing  relationships  -  child  tables 

1 

tdsAddressType 

0  -  none 

1  -  tbIAddress 

Note:  Standard  NJWaTr  contains  3  types 

1 

tdsConveyanceActionCategory 

0  -  none 

1  -  tdsConveyanceAction 

Note:  Standard  NJWaTr  contains  25  category  terms 

1 

tdsConveyance  Type 

0  -  none 

1  -  tbIConveyance 

Note:  Standard  NJWaTr  contains  7  types 

1 

tdsCriticalArea 

0  -  none 

1  -  tadSiteResource 

Note:  Standard  NJWaTr  contains  2  New  Jersey  areas,  plus  one  record  (ID  =  0)  representing  an  unknown  condition,  and 
another  (ID=9)  representing  a  Not  Applicable  condition;  must  be  modified  for  use  outside  of  the  New  Jersey  area 

1 

tdsCriticaIZone 

0  -  none 

1  -  tadSiteResource 

Note:  Standard  NJWaTr  contains  5  New  Jersey  zones,  plus  one  record  (ID  =  0)  representing  an  unknown  condition,  and 
another  (ID=9)  representing  a  Not  Applicable  condition;  must  be  modified  for  use  outside  of  the  New  Jersey  area 

1 

tdsDroughtRegion 

0  -  none 

1  -  tdsMCD 

Note:  Standard  NJWaTr  contains  6  New  Jersey  regions,  plus  one  record  (ID  =  0)  representing  a  Not  Applicable  condition; 
must  be  modified  for  use  outside  of  the  New  Jersey  area 

1 

tdsLocationScale 

0  -  none 

1  -  tbILocation 

Note:  Standard  NJWaTr  contains  7  scales,  plus  one  record  (ID 

=  0)  representing  an  unknown  condition 

1 

tdsOwnerType 

0  -  none 

1  -  tbIOwner 

Note:  Standard  NJWaTr  contains  6  types,  plus  one  record  (ID  = 

0)  representing  an  unknown  condition 

1 

tdsPermitSeries 

0  -  none 

1  -  tbIPermit 

Note:  Standard  NJWaTr  contains  9  New  Jersey  Permit  Series  classifications,  plus  one  record  (ID  =  0)  representing  an 
unknown  condition;  must  be  modified  for  use  outside  of  the  New  Jersey  area 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order 

Table  name 

Incoming  relationships  -  parent  tables 

Outgoing  relationships  -  child  tables 

1 

tdsResourceType 

0  -  none 

1  -  tdsWaterBodyType 

Note:  Standard  NJWaTr  contains  6  types,  plus  one  record  (ID  = 

=  0)  representing  an  unknown  condition 

1 

tdsSiteTypeCategory 

0  -  none 

1  -  tdsSiteTypeSubcategory 

Note:  Standard  NJWaTr  contains  6  category  terms,  plus  one  record  (ID  =  0)  representing  an  unknown  condition  and  used 
temporarily  when  loading  Site  data 

1 

tdsState 

0  -  none 

2  -  tdsCounty,  tadLocationState 

Note:  Standard  NJWaTr  contains  5  states,  plus  one  record  (ID 
use  with  states  not  contiguous  with  New  Jersey 

=  0)  representing  an  unknown  condition;  must  be  modified  for 

1 

tdsTimelnterval 

0  -  none 

2  -  tadSiteDetail,  tbITransfer 

Note:  Standard  NJWaTr  contains  1 1  intervals 

1 

tdsUseGroup 

0  -  none 

1  -  tdsUseType 

Note:  Standard  NJWaTr  contains  7  New  Jersey  groups,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  must  be 
modified  for  use  outside  of  the  New  Jersey  area 

1 

tds  VolumeUnitDecimal 

0  -  none 

1  -  tdxVolumeUnit 

Note:  Standard  NJWaTr  contains  10  decimal  terms 

1 

tds  VolumeUnitQuantity 

0  -  none 

1  -  tdxVolumeUnit 

Note:  Standard  NJWaTr  contains  6  quantity  terms 

1 

tdsWaterRegion 

0  -  none 

1  -  tdsWaterMgmntArea 

Note:  Standard  NJWaTr  contains  5  New  Jersey  regions,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  must  be 
modified  for  use  outside  of  the  New  Jersey  area 

1 

tdxConveyanceDetailLabel 

0  -  none 

1  -  tadConveyanceDetail 

Note:  Standard  NJWaTr  contains  5  labels;  populate  with  appropriate  values  as  needed 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 

Incoming  relationships  -  parent  tables  Outgoing  relationships  -  child  tables 

1  tdxLocationDetMethod 

0  -  none  1  -  tbILocation 

Note:  Standard  NJWaTr  contains  10  methods,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  populate  with 
appropriate  values  as  needed 

1  tdxResourceDetailLabel 

0  -  none  2  -  tadResourceDetail,  tasWaterBodyDetailLabel 

Note:  Standard  NJWaTr  contains  5  labels;  populate  with  appropriate  values  as  needed;  labels  may  be  paired  with  records 
from  tdsWaterBodyType  to  create  valid  combinations  in  tasWaterBodyDetailLabel 

1  tdxSiteDetailCategory 

0  -  none  1  -  tdxSiteDetailLabel 

Note:  Standard  NJWaTr  contains  5  category  terms;  populate  with  appropriate  values  as  needed 

1  tdxStaff 

0  -  none  1  -  tbIVolume 

L/l 

Note:  Can  be  pre-populated  with  intended  NJWaTr  data  entry  staff;  populate  with  appropriate  values  as  needed 

1  tdxSystemType 

0  -  none  1  -  tdxSystem 

Note:  Standard  NJWaTr  contains  6  types;  populate  with  appropriate  values  as  needed 

1  tdxVolumeDetailLabel 

0  -  none  1  -  tadVolumeDetail 

Note:  Standard  NJWaTr  contains  1  label  ("Accuracy”);  populate  with  appropriate  values  as  needed 

1  tdxVolumeMethodCategory 

0  -  none  1  -  tdxVolumeMethod 

Note:  Standard  NJWaTr  contains  1 1  category  terms,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  populate 
with  appropriate  values  as  needed 

2  tbIAddress 

1  -  tdsAddressType  2  -  tasOwnerAddress,  tasSiteAddress 

Note:  Some  fields  are  optional;  care  should  be  excercised  to  avoid  duplicate  entries  having  minor  spelling  variations 

2  tbILocation 

2  -  tdxLocationDetMethod,  tdsLocationScale  5  -  tadLocationCounty,  tadLocationHUC, 

tadLocationMCD,  tadLocationState,  tbISite 

Note:  Location  is  required  for  a  Site;  a  default  Location  record  (ID  =  0)  representing  an  unknown  condition  is  provided 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 


Incoming  relationships  -  parent  tables 


Outgoing  relationships  -  child  tables 


L/i 


2  tbIOwner 


1  -  tdsOwnerType 


6  -  tasConveyanceOwner,  tdxDataSource, 

tasOwnerAddress,  tasOwnerPermit,  tbIResource, 
tbISite 


Note:  Some  fields  are  optional;  a  default  Owner  record  (ID  =  0)  representing  an  unknown  condition  is  provided;  an  Owner  is 
required  for  a  Site,  Resource,  and  DataSource;  avoid  spelling  variation  duplicates;  ParentOwnerJD  is  recursive  and 
optional 


2 

tdsConveyanceAction 

1  -  tdsConveyanceActionCategory  1  -  tbtConveyance 

Note:  Standard  NJWaTr  contains  180  actions;  a  maintenance  update  query  is  needed  to  create  the  ConveyanceActionPhrase 
after  any  new  actions  are  entered 

2 

tdsCounty 

1  -  tdsState  2  -  tadLocationCounty,  tdsMCD 

Note:  Standard  NJWaTr  contains  177  counties  for  the  New  Jersey  area,  plus  one  record  (ID  =  0)  representing  an  unknown 
condition;  must  be  modified  for  use  with  states  not  contiguous  with  New  Jersey 

2 

tdsSite  TypeSubcategory 

1  -  tdsSiteTypeCategory  1  -  tdsSiteType 

Note:  Standard  NJWaTr  contains  12  subcategory  terms,  plus  one  record  (ID  =  0)  representing  an  unknown  condition  and 
used  temporarily  when  loading  Site  data 

2 

tdsUseType 

1  -  tdsUseGroup  3  -  tadUseConsumedFraction,  tbISite,  tadSiteUseType 

Note:  Standard  NJWaTr  contains  37  type  terms  for  New  Jersey,  plus  one  record  (ID  =  0)  representing  an  unknown  condition: 
must  be  modified  for  use  outside  of  the  New  Jersey  area 

2 

tds  Wa  ter  Body  Type 

1  -  tdsResourceType  2  -  tbIResource,  tasWaterBodyDetailLabel 

Note:  Standard  NJWaTr  contains  13  types,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  water  body  types 
may  be  paired  with  records  from  tdxResourceDetailLabel  in  tasWaterBodyDetailLabel  to  create  valid  combinations 

2 

tds  WaterMgmntArea 

1  -  tdsWaterRegion  1  -  tdsHUC 

Note:  Standard  NJWaTr  contains  20  New  Jersey  areas,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  must  be 
modified  for  use  outside  of  the  New  Jersey  area 

2 

tdxSiteDetailLabel 

1  -  tdxSiteDetailCategory  2  -  tadSiteDetail,  tasSiteTypeDetailLabel 

Note:  Standard  NJWaTr  contains  15  labels;  populate  with  appropriate  values  as  needed;  labels  may  be  paired  with  records 
from  tdsSiteType  to  create  valid  combinations  in  tasSiteTypeDetailLabel 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 

Incoming  relationships  -  parent  tables  Outgoing  relationships  -  child  tables 

2  tdxSystem 

1  -  tdxSystemType  1  -  tasSystemSite 

Note:  System  identities  may  be  created  before  establishing  Site  records,  and  the  Site  associates  established  in 
tasSystemSite  later;  avoid  spelling  variation  duplicates;  ParentSystemJD  is  recursive  and  optional 

2  tdxVolumeMethod 

1  -  tdxVolumeMethodCategory  1  -  tbIVolume 

Note:  Standard  NJWaTr  contains  41  methods,  plus  one  record  (ID  =  0)  representing  an  unknown  condition;  populate  with 
appropriate  values  as  needed 

2  tdxVolumeUnit 

2  -  tdsVolumeUnitDecimal,  tdsVolumeUnitQuantity  1  -  tbIVolume 

Note:  Standard  NJWaTr  contains  10  unit  terms;  create  new  units  as  needed  by  combining  decimal  and  quantity  terms;  a 
maintenance  update  query  is  needed  to  establish  the  VolumeUnitPhrase  and  MGConversion  values  after  new  unit 
records  are  assembled 

3  tadLocationCounty 

L/l 

OS 

2  -  tdsCounty,  tbILocation  0  -  none 

Note:  CountyFraction  must  be  entered;  IsPrimaryCounty  is  optional  but  recommended 

3  tadLocationState 

2  -  tbILocation,  tdsState  0  -  none 

Note:  StateFraction  must  be  entered;  IsPrimaryState  is  optional  but  recommended 

3  tadUseConsumedFraction 

1  -  tdsUseType  0  -  none 

Note:  Use  of  this  table  is  optional;  to  use  as  intended,  each  UseType  to  associate  with  consumptive  use  should  have  one 
record  for  each  of  the  12  months  of  the  year 

3  tasOwnerAddress 

2  -  tbIAddress,  tbIOwner  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  an  Owner  with  an  Address 

3  tasWaterBodyDetailLabel 

2  -  tdxResourceDetailLabel,  tdsWaterBodyType  0  -  none 

Note:  Use  of  this  table  is  optional;  it  pairs  a  WaterBodyType  with  a  ResourceDetailLabel  to  establish  rules  for  which  labels  are 
appropriate  for  which  water  body  types 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 

Incoming  relationships  -  parent  tables  Outgoing  relationships  -  child  tables 

3  tbIConveyance 

2  -  tdsConveyanceAction,  tdsConveyanceType  6  -  tasConveyanceAHas,  tadConveyanceDetail, 

tasConveyanceOwner, 
tadConveyanceExpectedFraction, 
tadSiteConveyance,  tbITransfer 

Note:  Sites  at  Conveyance  end  points  need  to  be  known  before  creating  a  Conveyance;  a  record  here  should  be  followed 
immediately  by  establishing  the  end  points  in  tadSiteConveyance 

3  tbIResource 

2  -  tbIOwner,  tdsWaterBodyType  5  -  tadResourceStructure,  tadResourceStructure, 

tasResourceAlias,  tadResourceDetail, 
tadSiteResource 

Note:  Some  fields  are  optional:  a  default  Resource  record  (ID  =  0)  representing  an  unknown  condition  is  provided;  care  should 
be  used  to  create  a  unique  ResourceCodeName;  composite  Resources  can  be  separated  into  components  in 
tadResourceStructure 

3  tdsHUC 

1  -  tdsWaterMgmntArea  1  -  tadLocationHUC 

Note:  Standard  NJWaTr  contains  933  14-digit  HUCs  for  New  Jersey,  plus  one  record  (ID  =  0)  representing  an  unknown 
condition;  must  be  modified  for  use  outside  of  the  New  Jersey  area 

3  tdsMCD 

2  -  tdsCounty,  tdsDroughtRegion  1  -  tadLocationMCD 

Note:  Standard  NJWaTr  contains  4,478  MCDs  (town  equivalent)  for  the  New  Jersey  area,  plus  one  record  (ID  =  0) 
representing  an  unknown  condition;  must  be  modified  for  use  with  states  not  contiguous  with  New  Jersey 

3  tdsSiteType 

1  -  tdsSiteTypeSubcategory  2  -  tbISite,  tasSiteTypeDetailLabel 

Note:  Standard  NJWaTr  contains  35  types,  plus  one  record  (ID  =  0)  representing  an  unknown  condition  and  used  temporarily 
when  loading  Site  data;  site  types  may  be  paired  with  records  from  tdxSiteDetailLabel  to  create  valid  combinations  in 
tasSiteTypeDetailLabel 

3  tdxDataSource 

1  -  tbIOwner  5  -  tdxAliasLabel,  tdxPermitLabel,  tadResourceDetail, 

tadSiteDetail,  tbIVolume 

Note:  Populate  with  appropriate  values  as  needed;  a  default  DataSource  record  (ID  =  0)  representing  an  unknown  condition  is 
provided;  DataSource  is  required  for  tbIVolume,  tdxAliasLabel,  tdxPermitLabel,  and  the  detail  tables  for  Sites  and 
Resources 

4  tadConveyanceDetail 

2  -  tbIConveyance,  tdxConveyanceDetailLabel  0  -  none 

Note:  ConveyanceDetail  must  be  entered 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 

Incoming  relationships  -  parent  tables  Outgoing  relationships  -  child  tables 

4  tadConveyanceExpectedFraction 

1  -  tbIConveyance  0  -  none 

Note:  Use  of  this  table  is  optional;  to  fully  use  as  intended,  each  Conveyance  should  have  a  default  record  defining  the  current 
apportionment  of  the  sending  Site's  accumulation 

4  tadLocationHUC 

2  -  tdsHUC,  tbILocation  0  -  none 

Note:  HUCFraction  must  be  entered:  IsPrimaryHUC  is  optional  but  recommended 

4  tadLocationMCD 

2  -  tbILocation,  tdsMCD  0  -  none 

Note:  MCDFraction  must  be  entered;  IsPrimaryMCD  is  optional  but  recommended 

4  tadResourceDetail 

3  -  tdxDataSource,  tbIResource,  tdxResourceDetailLabel  0  -  none 

Note:  ResourceDetail  and  ResourceDetailEffectiveDate  must  be  entered 

4  tadResourceStructure 

2  -  tbIResource,  tbIResource  0  -  none 

Note:  Use  of  this  table  is  reserved  for  composite  Resources  that  need  to  be  recognized  by  their  component  Resources; 
ParentResourceFraction  and  IsPrimaryResource  are  optional  but  recommended  fields 

4  tasConveyanceOwner 

2  -  tbIConveyance,  tbIOwner  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Conveyance  with  an  Owner 

4  tasSiteTypeDetailLabel 

2  -  tdxSiteDetallLabel,  tdsSIteType  0  -  none 

Note:  Use  of  this  table  is  optional;  it  pairs  a  SiteType  with  a  SiteDetailLabel  to  establish  rules  for  which  labels  are  appropriate 
for  which  site  types 

4  tbISite 

4  -  tbILocation,  tbIOwner,  tdsSiteType,  tdsUseType  8  -  tasSiteAddress,  tasSiteAlias,  tadSiteConveyance, 

tadSiteDetail,  tasSitePermit,  tadSiteResource, 
tadSiteUseType,  tasSystemSite 

Note:  Standard  NJWaTr  contains  three  generic  Sites;  SiteContact  field  is  optional  but  recommended;  related  records  for 
Addresses,  associated  Resource,  and  all  Permit  and  Alias  designations  can  be  completed  immediately  following  Site 
entry 

4  tbITransfer 

2  -  tbIConveyance,  tdsTimelnterval  1  -  tbIVolume 

Note:  A  default  tbIVolume  record  should  be  created  simultaneously  with  each  tbITransfer  record;  a  maintenance  update  query 
is  needed  after  new  records  are  entered  to  translate  the  default  Volume  into  common  units  for  the  field  VolumeMG 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 

Incoming  relationships  -  parent  tables  Outgoing  relationships  -  child  tables 

4  tdxAliasLabel 

1  -  tdxDataSource  1  -  tbIAIias 

Note:  May  be  pre-populated  with  anticipated  label  values,  or  a  Label  value  may  be  created  just  prior  to  creating  a  tbIAIias 
record 

4  tdxPermitLabel 

1  -  tdxDataSource  1  -  tbIPermit 

Note:  May  be  pre-populated  with  anticipated  label  values,  or  a  Label  value  may  be  created  just  prior  to  creating  a  tbIPermit 
record 

5  tadSiteConveyance 

2  -  tbIConveyance,  tbISite  0  -  none 

Note:  'From'  or  'To'  must  be  entered;  each  Conveyance  should  be  validated  to  have  two  Site  endpoints,  and  each  Site  should 
be  validated  as  being  associated  with  at  least  one  Conveyance 

5  tadSiteDetail 

4  -  tdxDataSource,  tbISite,  tdxSiteDetailLabel,  0  -  none 

tdsTimelnterval 

SO 

Note:  Must  enter  SiteDetailEffectiveDate  and  SiteDetailValue 

5  tadSiteResource 

4  -  tdsCriticalArea,  tdsCrltlcalZone,  tbIResource,  tbISite  0  -  none 

Note:  Only  Sites  having  a  "Resource  Interactor"  SiteTypeCategory  are  valid  here;  one  Resource  is  associated  with  a  Site 
(may  be  a  composite);  wells  require  non-default  Critical  Area  and  Zone  selections;  ConnectionCount  is  optional  but 
recommended 

5  tadSiteUseType 

2  -  tbISite,  tdsUseType  0  -  none 

Note:  Use  of  this  table  is  optional;  each  Site  is  always  assigned  a  primary  use,  but  this  table  contains  an  alternative 
apportionment  of  the  Site's  water  data  among  more  than  one  UseType 

5  tasSiteAddress 

2  -  tbIAddress,  tbISite  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Site  with  an  Address 

5  tasSystemSite 

2  -  tbISite,  tdxSystem  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Site  with  a  System 

5  tbIAIias 

1  -  tdxAliasLabel  3  -  tasConveyanceAlias,  tasResourceAlias,  tasSiteAlias 

Note:  Can  be  created  simultaneously  with  an  AliasLabel 

Table  1.  Table  loading  order  and  related  information  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Loading 

order  Table  name 

Incoming  relationships  -  parent  tables  Outgoing  relationships  -  child  tables 

5  tbIPermit 

2  -  tdxPermitLabel,  tdsPermitSeries  2  -  tasOwnerPermit,  tasSitePermit 

Note:  Site  or  Owner  must  be  known  before  creating  a  Permit  association 

5  tbIVolume 

5  -  tdxDataSource,  tdxStaff,  tbITransfer,  1  -  tadVolumeDetail 

tdxVolumeMethod,  tdxVolumeUnit 

Note:  Volume  information  can  be  entered  simultaneously  with  its  tbITransfer  record 

6  tadVolumeDetail 

2  -  tbIVolume,  tdxVolumeDetailLabel  0  -  none 

Note:  VolumeDetail  must  be  entered 

6  tasConveyanceAlias 

2  -  tbIAIias,  tbIConveyance  0  -  none 

os  - 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Conveyance  with  an  Alias 

“  6  tasOwnerPermit 

2  -  tbIOwner,  tbIPermit  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  an  Owner  with  a  Permit 

6  tasResourceAlias 

2  -  tbIAIias,  tbIResource  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Resource  with  an  Alias 

6  tasSiteAlias 

2  -  tbIAIias,  tbISite  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Site  with  an  Alias 

6  tasSitePermit 

2  -  tbIPermit,  tbISite  0  -  none 

Note:  No  special  considerations  other  than  verifying  the  pairing  of  a  Site  with  a  Permit 

The  first  query,  qrmVolumeUnitConversionFactor,  creates  the  phrase  and  conversion  factor  from 
fields  provided  for  that  puipose  in  the  two  component  tables.  The  phrase  is  constructed  by  combining  unit 
terms  from  the  fields  DecimalUnit  and  QuantityUnit.  The  conversion  factor  is  calculated  as  the  product  of 
the  ConversionToMillion  and  ConversionToGallon  fields  of  the  component  tables.  The  SQL  statement  for 
this  query  is 

SELECT  [tdxVolumeUnit] . [VolumeUnit_ID] ,  Ilf ( [tdsVolumeUnitDecimal] ! [DecimalUnit]  = 
'one', [tdsVolumeUnitQuantity] ! [QuantityUnit] ,  [tdsVolumeUnitDecimal] ! [DecimalUnit]  & 

"  "  &  [tdsVolumeUnitQuantity] ! [QuantityUnit] ) 

AS  VolumeUnitPhrase ,  tdsVolumeUnitQuantity] ! [ConversionToGallon]  * 
[tdsVolumeUnitDecimal] ! [ConversionToMillion]  AS  MGConversion 
FROM  [tdsVolumeUnitQuantity] 

INNER  JOIN  ( [tdsVolumeUnitDecimal] 

INNER  JOIN  [tdxVolumeUnit] 

ON  [tdsVolumeUnitDecimal] . [VolumeUnitDecimal_ID]  = 

[tdxVolumeUnit] . [VolumeUnitDecimal_ID] ) 

ON  [tdsVolumeUnitQuantity] . [VolumeUnitQuantity_ID]  = 

[tdxVolumeUnit] . [VolumeUnitQuantity_ID] ; 

Note  the  Ilf  statement  near  the  beginning  of  the  query.  When  the  decimal  component  of  the  construct¬ 
ed  unit  is  “one,”  no  explicit  statement  of  that  is  desirable  in  the  actual  unit  phrase  itself.  The  Ilf  constraint 
in  the  above  query  presents  the  volume  term  when  the  decimal  term  is  “one;”  otherwise,  it  presents  the 
decimal  term,  a  space,  and  the  volume  term.  Not  using  the  word  “one”  avoids  creating  an  awkward  phrase 
for  the  unit;  for  example,  the  phrase  value  “cubic  feet”  is  the  desired  phrase  compared  with  “one  cubic  feet.” 

The  tdxVolumeUnit  table  is  updated  by  running  the  query,  qrmVolumeUnitUpdateNEW.  It  identi¬ 
fies  records  where  MGConversion  =  “-1”  and  applies  the  above  query  only  to  those  records  that  need  the 
update  in  the  VolumeUnitPhrase  and  MGConversion  fields.  The  SQL  statement  for  this  query  is 

UPDATE  [qrmVolumeUnitConversionFactor] 

INNER  JOIN  [tdxVolumeUnit] 

ON [qrmVolumeUnitConversionFactor] . [VolumeUnit_ID]  =  [tdxVolumeUnit] . [VolumeUnit_ID] 

SET  [tdxVolumeUnit] . [MGConversion]  = 

[qrmVolumeUnitConversionFactor] . [MGConversion] , [tdxVolumeUnit] . [VolumeUnitPhrase]  = 
[qrmVolumeUnitConversionFactor] . [VolumeUnitPhrase] 

WHERE  ( ( ( [tdxVolumeUnit] . [MGConversion] ) =-l) ) ; 

A  valiant  on  the  second  query  is  provided  in  NJWaTr  to  update  all  the  VolumeUnit  phrases  and  con¬ 
version  factors  in  the  tdxVolumeUnit  table.  This  is  used  whenever  conversion  factors  need  to  be  corrected 
from  changes  made  to  the  component  tables.  The  query  qrmVolumeUnitUpdateALL  is  identical  to  the 
query  immediately  above,  except  that  it  lacks  the  constraint  of  updating  tdxVolumeUnit  records  only  where 
MGConversion  =  “-1”  (the  SQL  WHERE  clause  is  not  used). 


Volume  Conversion  to  Common  Units  and  Updating  Transfers 

Original  Volume  data  for  a  Transfer  are  entered  into  the  tblVolume  table  and  consist  of  a  value  and 
the  units  for  that  value  as  originally  received  or  created  using  a  specified  method  and  data  source.  The  units 
are  identified  in  NJWaTr  by  a  selection  from  the  tdxVolumeUnit  table.  The  default  Volume  value  for  each 
Transfer  must  be  converted  to  common  units  (MG,  million  gallons)  and  entered  into  the  tblTransfer  table 
in  the  field  VolumeMG.  Initially,  the  VolumeMG  value  for  newly  created  Transfers  is  assigned  a  default 
value  of  “-1”,  and  this  is  used  as  a  flag  for  values  that  have  not  yet  been  updated.  Replacing  the  “-1”  flag 
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with  a  valid,  converted  Volume  value  is  done  by  using  two  queries.  One  query  sets  things  up  and  the  other 
performs  the  update.  Only  the  second  query  must  be  run. 

The  first  query  is  qrmTransferConvertDefault Volumes;  it  identifies  the  default  Volume  entries  in 
tblVolume  for  each  record  in  tblTransfer  and  calculates  the  equivalent  converted  Volume  in  MG  common 
units  based  on  the  original  VolumeUnit.  The  actual  calculation  is  RawVolumeValue  *  MGConversion.  This 
query  is  not  run  but  only  provides  the  set  of  records  that  represents  converted  default  rates  from  tblVolume 
to  the  next  query.  The  SQL  statement  for  this  query  is 

SELECT  [tblVolume] . [Transf er_ID] ,  [RawVolumeValue] * [MGConversion] 

AS  ConvertedVolume 
FROM  [tdxVolumeUnit] 

INNER  JOIN  [tblVolume] 

ON  [tdxVolumeUnit] . [VolumeUnit_ID]  =  [tblVolume] . [VolumeUnit_ID] 

WHERE  ( ( ( [tblVolume] . [IsDefaultVolume] ) =Yes) ) ; 

The  second  query,  qrmTransferUpdateNEW,  is  run  to  perform  the  update.  This  query  links 
tblTransfer  records  where  VolumeMG  =  “-1”  to  the  first  query’s  set  of  converted  Volume  values  and 
replaces  the  default  “-1”  VolumeMG  values  in  tblTransfer.  The  SQL  statement  for  this  query  is 

UPDATE  [tblTransfer] 

INNER  JOIN  [qrmTransf erConvertDef aultVolumes] 

ON  [tblTransfer] . [Transf er_ID]  =  [qrmTransf erConvertDef aultVolumes] . [Transf er_ID] 

SET  [tblTransfer] . [VolumeMG]  =  [qrmTransf erConvertDef aultVolumes] . [ConvertedVolume] 
WHERE  ( ( (tblTransfer .VolumeMG) =- 1) ) ; 

A  variant  on  the  second  query  is  provided  in  NJWaTr  to  update  all  the  VolumeMG  values  in  the 
tblTransfer  table.  This  is  to  be  used  whenever  a  conversion  factor  for  one  or  more  records  in  tdxVolumeUnit 
is  changed  or  when  adjustments  might  be  made  to  RawVolumeValue s  in  the  tblVolume  table.  The  query 
qrmTransferUpdateALL  is  identical  to  the  query  immediately  above,  except  that  it  lacks  the  constraint  of 
updating  Transfer  records  only  where  VolumeMG  =  “-1”  (the  SQL  WHERE  clause  is  not  used). 


Conveyance  Action  Phrase  Updates 

The  domain  table  tdsConveyanceAction  provides  a  list  of  Site-type  functions  performed  on  a  Con¬ 
veyance  and  has  a  phrase  field  ( ConveyanceActionPhrase )  to  describe  that  action  (for  example,  the  phrase 
“From  ground-water  withdrawal  To  potable-water  treatment  plant”).  The  phrase  is  constructed  from  the 
same  terms  used  in  the  tdsSiteType  table  to  describe  the  Sites  at  the  To  and  From  ends  of  the  Conveyance. 
Exact  correspondence  between  terms  used  to  describe  Sites  and  those  used  to  describe  Site  connections 
(Conveyances)  is  desirable.  Although  the  tdsConveyanceAction  domain  table  is  considered  complete 
(static),  the  ability  to  update  the  phrase  field  will  accommodate  any  potential  changes  to  terms  used  in  the 
tdsSiteType  table.  In  the  event  that  additions  are  made  to  the  tdsConveyanceAction  domain,  the  same  update 
facility  will  create  the  correct  ConveyanceActionPhrase. 

The  tdsConveyanceAction  table  contains  two  pseudo-key  fields,  SiteTypeFromID  and  SiteTypeToID. 
These  fields  contain  values  that  correspond  to  SiteType_ID  values  in  tdsSiteType.  The  purpose  of  the 
pseudo-keys  is  to  allow  transient  linkages  to  be  made  between  the  tdsSiteType  table  and  the 
tdsConveyanceAction  table  to  automatically  update  the  phrase  field.  Updating  the  field 
ConveyanceActionPhrase  requires  four  queries — three  to  set  things  up  and  one  to  perform  the  update.  Only 
the  last  query  must  be  run. 
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Because  there  is  a  one-to-two  relationship  between  a  ConveyanceAction  and  its  two  SiteType  ends, 
two  queries  arc  needed  to  separately  establish  SiteType  terms  for  the  From  and  To  ends  of  the  Conveyance. 
A  link  is  made  between  the  tdsConveyanceAction  and  tdsSiteType  tables,  and  type  terms  arc  collected  sep¬ 
arately  with  the  text  “From”  and  “To”  added.  The  names  and  SQL  statements  for  these  two  queries  follow. 

qrmConvActionSiteTypeFrom 

SELECT  [tdsConveyanceAction] . [ConveyanceAction_ID] ,  ('From  '  &  [SiteType]) 

AS  [FromSiteType] 

FROM  [tdsConveyanceAction] 

INNER  JOIN  [tdsSiteType] 

ON  [tdsConveyanceAction] . [SiteTypeFromID]  =  [tdsSiteType] . [SiteType_ID] ; 

qrmConvActionSiteTypeTo 

SELECT  [tdsConveyanceAction] . [ConveyanceAction_ID] ,  ('To  '  &  [SiteType]) 

AS  [ToSiteType] 

FROM  [tdsConveyanceAction] 

INNER  JOIN  [tdsSiteType] 

ON  [tdsConveyanceAction] . [SiteTypeToID]  =  [tdsSiteType] . [SiteType_ID] ; 

Next,  a  query  is  used  to  assemble  the  two  parts  into  a  phrase  that  is  based  on  their  common 
Convey anceAction_lD  values.  The  query  and  SQL  statement  that  accomplish  this  arc 

qrmConvActionPhrase 

SELECT  [qrmConvActionSiteTypeFrom] . [ConveyanceAction_ID] , 

( [FromSiteType]  &  '  '  &  [ToSiteType] )  AS  [ConveyanceActionPhrase] 

FROM  [qrmConvActionSiteTypeFrom] 

INNER  JOIN  [qrmConvActionSiteTypeTo] 

ON  [qrmConvActionSiteTypeFrom] . [ConveyanceAction_ID]  = 

[qrmConvActionSiteTypeTo] . [ConveyanceAction_ID] ; 

The  last  query  applies  the  results  of  the  previous  query  to  perform  the  update  of  the  field  Conveyance¬ 
ActionPhrase  in  table  tdsConveyanceAction.  This  is  the  only  query  that  is  actually  run;  the  others  provide 
the  partial  solutions  to  the  update  procedure.  The  query  and  SQL  statement  for  this  procedure  arc 

qrmConvActionPhraseUpdate 


UPDATE  [tdsConveyanceAction] 

INNER  JOIN  [qrmConvActionPhrase]  ON  [tdsConveyanceAction] . [ConveyanceAction_ID]  = 
[qrmConvActionPhrase] . [ConveyanceAction_ID] 

SET  [tdsConveyanceAction] . [ConveyanceActionPhrase]  = 

[qrmConvActionPhrase] . [ConveyanceActionPhrase] ; 


Construction  and  Use  of  Views 

The  number  of  individual  NJWaTr  tables  and  the  complexity  of  relationships  between  them  have  the 
potential  to  be  confusing  to  users.  Although  the  primary  reason  for  most  of  the  individual  tables  is  to  respect 
the  rules  of  normalization  and,  thus,  provide  significant  integrity  and  list-maintenance  advantages  for  the 
data,  the  task  of  manually  collecting  the  correct  sets  of  tables  in  a  query  to  perform  routine  exploratory  tasks 
should  not  be  an  impediment  to  using  the  database.  Most  of  the  sets  of  related  tables  in  NJWaTr  subject 
areas  have  been  pre-assembled  into  single  objects  for  further  manipulation.  These  general-purpose  queries 
arc  called  “Views”  and  are  essentially  virtual  tables;  they  do  not  exist  as  physical  file  structures  but  rather 


63 


as  named  SQL  statements  stored  in  the  database.  When  run  or  used  in  forms  or  reports.  Views  create  the 
appearance  of,  and  act  like,  a  physical  table. 

A  typical  View  is  a  query  that  begins  with  a  base  table,  then  gathers  attributes  (fields)  from  related 
tables  and  drops  the  keys  that  joined  them.  Thus,  fields  from  related  domain  and  data  tables  arc  added  to 
those  of  the  View  base  table.  Views  help  users  see  the  data  in  a  familiar  flatfile  or  spreadsheet  format  for 
browsing  and  checking  data  without  the  visual  distraction  of  keys  and  relationships.  Views  can  be  combined 
with  other  Views  to  create  elaborate  View  assemblies.  In  addition.  Views  can  be  used  to  export  a  physical 
flatfile  directly  to  file  types  that  can  be  imported  by  other  applications. 

Views  arc  stored  as  queries  with  a  qrv  prefix  in  NJWaTr.  In  most  cases,  a  View  is  a  complete 
assembly  of  nearest-neighbor-related  domain  tables  centered  on  a  single  subject  area.  After  a  View  is 
created,  it  then  can  be  combined  with  others  to  form  much  larger  data  objects  that  can  be  handled,  and  whose 
data  can  be  evaluated,  at  once.  In  some  Views,  there  is  an  abbreviated  assembly  of  items  due  to  one-to-many 
relationships  between  tables  that  compose  the  View.  An  example  of  the  latter  is  the  ignoring  of  non-default 
Volume  values  in  assembling  a  View  of  Transfers.  (Multiple  Volume  estimates  can  be  stored  for  a  single 
Transfer,  whereas  only  the  default  is  presented  in  the  View.)  Likewise,  each  Location’s  primary  state, 
county,  MCD,  and  HUC  arc  associated  with  the  qrvLocation  View,  instead  of  creating  many  new  columns 
for  those  instances  where  more  than  one  item  within  each  spatial  domain  relates  to  a  single  Location.  These 
compromises  might  affect  an  analysis  and  need  to  be  recognized;  users  arc  encouraged  to  create  their  own 
optimized  Views  for  specific  needs. 


Example  of  View  Construction 

An  example  of  View  construction  is  provided  to  illustrate  the  method  and  result  common  to  all 
standard  NJWaTr  Views.  The  Location  subject  area  in  NJWaTr  consists  of  14  tables  (fig.  10).  Four  of  those 
arc  association  tables  for  storing  multiple  states,  counties,  MCDs,  and  HUCs  for  a  Location,  and  for  each 
Location  only  one  of  each  is  designated  as  the  primary.  Five  queries  arc  needed  to  create  a  View  of  the 
Location  subject  area — four  to  identify  the  primary  selections  from  the  spatial  domains  (if  present)  for  each 
Location  (qrvLocationPrimaryState,  qrvLocationPrimaryCounty,  qrvLocationPrimaryMCD,  and 
qrvLocationPrimaryHUC),  and  one  to  incorporate  those  queries  and  gather  other  fields  from  domain 
tables  with  the  base  tblLocation  table  fields  (qrvLocation).  Note  that  the  MCD  and  HUC  domains  have 
their  own  higher  level  domains,  so  the  gathering  of  primary  MCDs  includes  the  Drought  Region  in  which 
they  occur,  and  the  primary  HUCs  include  the  related  Water  Management  Area  and  larger  Water  Region. 

The  three  tables  and  four  subqueries  involved  in  the  Location  View  arc  shown  in  figure  19  as  they 
would  be  seen  in  the  upper  panel  of  the  MS  Access  query  Design  view.  Note  the  arrows  on  the  relationship 
lines  that  link  fields  in  the  base  table  to  the  same  field  in  the  subqueries  and  domains;  these  indicate  that  a 
LEFT  JOIN  has  been  established  in  SQL  to  ensure  that  the  query  returns  all  records  from  tblLocation ,  even 
when  no  primary  entries  arc  present  in  the  subqueries  for  a  particular  Location_ID  value. 

The  qrvLocation  View  is  built  to  collect  all  non-key  fields  from  all  joined  tables  and  can  use  the 
Location_ID  to  serve  as  the  key  for  the  entire  assembly.  The  result  is  a  single  virtual  table  where  each  record 
describes  a  Location  by  using  39  data  fields  (plus  the  LocationMemo  field)  anchored  to  the  Location_ID 
key.  The  appearance  of  the  qrvLocation  View  when  selected  for  use  in  other  queries  also  is  shown  in  figure 
19.  This  virtual  table  can  be  used  in  other  queries,  manipulated  in  forms  and  reports,  or  exported  to  spread¬ 
sheets  or  text  files  without  further  regal'd  for  the  complex  of  14  original  tables  and  4  preliminary  queries  that 
formed  it. 
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Figure  19.  A  View  assembly  (left)  and  a  virtual  table  (right,  not  all  fields  shown)  focused  on  the  tbILocation  table. 


Another  type  of  View  is  created  using  a  crosstab  query  in  MS  Access.  Crosstab  queries,  also  known 
as  pivot  queries,  create  a  table  View  with  new  columns  based  on  values  in  a  field  and  are  very  useful  for 
denormalizing  or  rotating  data  stored  in  or  through  association  tables.  For  example,  Owner  Permits  are 
assigned  by  pairing  an  Owner_ID  with  a  Permit _ID  in  tasOwnerPermit  and  refer  to  an  entry  in  tblPermit. 
To  determine  all  the  Permits  associated  with  Owners,  one  can  create  a  crosstab  query  of  tblPermit  and 
related  tables  and  use  the  PennitLcibel  as  the  source  of  the  new  column  labels.  The  result  is  a  virtual  table 
with  Owner _ID  as  the  key  and  a  column  for  each  PermitLabel  associated  with  Owners.  The  query  layout  in 
MS  Access  and  output  for  some  test  data  arc  illustrated  in  figure  20;  each  of  the  four  PennitLabeh  that  were 
associated  with  Owner  Permits  are  presented  as  columns  anchored  to  individual  Owner _IDs.  This  View  can 
be  linked  directly  to  the  tblOwner  table  through  the  Owner _ID  to  provide  the  Permits  as  extended  Owner 
attributes.  The  column  name  could  be  made  more  informative  by  concatenating  the  PennitLcibel  and  the 
DataSource  descriptor  values. 

Views  can  be  linked  to  other  Views  to  create  large  customized  flatfile  objects  for  export,  for  use  in 
forms  and  reports,  or  for  any  other  purpose.  An  example  of  how  such  a  complex  object  would  be  assembled 
is  shown  in  figure  21;  Views  of  Site,  Resource,  Owner,  and  Location  are  combined  to  provide  a  selected 
subset  of  37  Site  descriptors  from  29  original  tables  (4  basic  data,  19  domain,  and  6  association)  anchored 
to  a  single  Site_ID  key.  The  virtual  table  resulting  from  the  View  and  a  form  that  uses  most  of  the  fields  is 
shown  in  figure  22.  The  form  demonstrates  an  exploratory  tool  for  the  NJWaTr  data  model.  In  MS  Access, 
drill-down  filtering  of  data  is  possible  directly  within  the  form,  and  the  select  subset  of  Sites  gathered  on  the 
basis  of  multiple-field  filter  criteria  can  be  saved  for  later  reference  with  a  query  created  from  the  form. 
Custom  Views  can  be  constructed  and  combined  with  forms  to  create  specialized  exploratory  tools. 


Standardized  and  Optimized  Views 

NJWaTr  includes  27  pre-assembled  standard  Views.  These  are  listed  along  with  their  base  PK  and  a 
brief  description  in  table  2.  These  Views  arc  assembled  by  gathering  fields  focused  on  each  major  subject 
area  in  the  database.  The  four  preliminary  Location  Views  that  gather  only  the  primary  selections  from  the 
spatial  domains  are  included,  along  with  a  View  that  reveals  the  parent/child  structure  of  composite  Re¬ 
sources.  Views  that  arc  based  on  association  tables  can  be  modified  easily  for  crosstabulation,  as  described 
previously,  to  create  denormalized  structures  for  Address,  Permit,  Alias,  and  User-Defined  Detail  tables, 
thereby  creating  new  virtual  fields  associated  with  subject  area  PKs.  The  standard  Views  will  produce 
equivalent  output  from  any  independent  implementation  of  NJWaTr  (different  data,  but  comparable  views). 

The  standard  Views  can  be  used  as  templates  for  creating  custom  optimized  queries  and  Views.  The 
standard  View  contains  all  value  fields  from  nearby  tables,  and  the  underlying  query  might  perform  slug¬ 
gishly  on  large  data  files.  A  custom  query  can  drop  unnecessary  tables,  fields,  and  relationships  from  a 
standard  View,  and  this  economy  will  significantly  improve  performance.  Custom  queries  that  start  with  a 
View  template  can  rearrange  or  rename  fields  and  impose  conditional  criteria,  thereby  creating  precise 
subsets  of  data  in  custom  formats.  An  optimal  View  would  include  only  those  tables  containing  the  query 
output  fields  and  any  other  tables  needed  to  create  a  relational  pathway  between  those  tables.  Many  of  the 
standard  Views  use  INNER,  LEFT,  and  RIGHT  JOINs  in  the  SQL  statement,  so  the  user  is  cautioned  to 
examine  a  query  structure  carefully  before  modifying  it  for  another  use. 
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bs8  Crosstab  Example  -  Owner  Permits  :  Crosstab  Query 


tasOwnerPermit 


* 

OwnerJD 

PermrtJD 


ItblPermit 

1 

M/ 

tdxPermitLabel 

* 

PermitJD 

PermitLabelJD 

PermitSeriesJD 

PermitNumber 

PermitMemo 

* 

PermitLabelJD 

DataSourceJD 

PermitLabel 

Per  mitLabe  Memo 

lOwner 

PermitLabel 

PermitNumber 

tasOwnerPermit 

tdxPermitLabel 

tbIPermit 

Group  Bv 

Group  Bv 

Min 

Row  Headinq 

Column  Headinq 

Value 

2^ 


Field 

Table 

Total 

Crosstab 

Sort 

Criteria 

or 


i?  Crosstab  Example  -  Owner  Permits  ;  Crosstab  Query 


Owner ID 

BWA 

Domestic  Wells 

DW  Service  Area 

NJPDES 

42 

CU0203 

43 

0035670. 001A 

44 

10742W 

45 

4037PS 

46 

AT0100 

47 

0020605. 001A 

48 

5281 

2101001 

49 

2101002 

50 

BU0116 

51 

5092 

201001 

52 

5131 

1301001 

53 

0020206. 001A 

54 

5178 

1302001 

55 

10562W 

335001 

56 

10762W 

57 

0133965. 001A 

58 

5255 

2102001 

59 

10759W 

105002 

60 

BU0122 

61 

BU0121 

eo. 

nnoQ/i  Rn  nni  a 

Record:  h  I  <  II  1 

►  1  h  |»+|  of  2901 

Figure  20.  A  crosstab-query  design  (top)  and  a  crosstab-query  output  (bottom). 
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as8  qrvSiteLocationOwnerResource  :  Select  Query 


qrvSite 

qrvSiteResource 

* 

* 

SiteJD 

SiteName 

SiteJD 

ResourceJD 

SiteContact 

SiteName 

LocationJD 

1 — ^ 

SiteType 

OwnerJD 

~v 

ResourceName 

SiteTypeCategory 

\ 

ResourceCodeName 

SiteTypeSubcategory 

\ 

ConnectionCount 

SiteType 

\ 

WaterBodyT  ype 

UseGroupCode 

\ 

ResourceType 

UseGroup 

\ 

GWorSW 

UseTypeCode 

\ 

CriticalAreaCode 

UseType 

\ 

CriticalArea 

SiteMemo 

\ 

CriticalZoneCode 

CriticalZone 

OwnerJD 

OwnerType 

OwnerName 

OwnerContact 

OwnerPhone 

ParentOwner 

ParentOwnerContact 

OwnerMemo 


qrvLocation 


LocationJD 

LocationDetMethod 

LocationScale 

LocationName 

LocationLatitude 

LocationLongitude 

NJEasting 

NJNorthing 

Country  Abbrv 

StateCode 

StateAbbrv 

PrimaryStatB 

StateLatitude 

StateLongitude 

StateCountyCode 

CountyCode 

PrimaryCounty 

CountyShortName 

CountyLatitude 

CountyLongitude 

StateMCDCode 

MCDCode 

MCDType 

PrimaryMCD 

MCDShortName 

MCDLatitude 

MCDLongitude 

DroughtReg  ionCode 

DroughtReg  ion 

WatershedCode 

PrimaryHUC14 

HI  iri4NUmo 


zl 


Figure  21 .  A  complex  View  assembly  made  up  of  other  Views. 
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qr  vSite  I  nformation 


* 

SiteJD 

SiteName 

SiteTypeCategory 

SiteT  ypeSubcategory 

SiteType 

SiteContact 

SiteMemo 

UseGroupCode 

UseGroup 

UseTypeCode 

UseType 

OwnerName 

OwnerType 

ParentOwner 

OwnerContact 

OwnerPhone 

LocationName 

LocationScale 

LocationDetMethod 

LocationLatitude 

LocationLongitude 

NJNorthing 

StateAbbrv 

CountyShortName 

MCDShortName 

PrimaryHUC14 

HUC14Name 

WatErshedCode 

WaterRegionCode 

WaterRegion 

WaterMgmntAreaCode 

WatErMgmntArea 

DroughtRegion 

ResourceName 

WatErBodyT  ype 

Critical  Area 

CriticaIZone 


Figure  22.  A  virtual  table  made  from  a  complex  View  assembly  (left)  and  a  form  based  on  the  virtual  table  (right). 


Table  2.  New  Jersey  Water-Transfer  Data  System  (NJWaTr)  standard  preassembled  views 

[MCD  is  a  Minor  Civil  Division  (town  or  other  subcounty  geographic  region)  of  the  U.S.  Census  Bureau;  HUC  is  a 
Hydrologic  Unit  Code  of  the  U.S.  Geological  Survey] 


View  (query)  name 

View  primary  key 

View  description 

qrv  Conveyance 

Conveyance _ID 

Joins  conveyance  action  and  type  domains  to  conveyances 

qrvConveyanceAlias 

Conveyance_ID 

Assembles  alias  data  applying  only  to  conveyances;  may 
be  crosstabbed 

qrvConveyanceDetail 

Conveyance_ID 

Joins  detail  label  domain  to  conveyance  details;  may  be 
crosstabbed 

qrvConveyanceOwner 

Conveyance_ID 

Assembles  owner  data  applying  only  to  conveyances;  also 
has  Owner  JD 

qrvLocation 

Location_ID 

Joins  scale  and  determination  method  domains,  and 
includes  only  primary  state,  county,  MCD  (town),  HUC, 
drought  region,  water  region  and  management  area 

qrvLocationPrimaryCounty 

Location_ID 

Assembles  primary  county  information  for  a  Location 

qrvLocationPrimaryHU  C 

Location_ID 

Assembles  primary  HUC  information  for  a  Location 

qrvLocationP  rimary  MCD 

Location_ID 

Assembles  primary  MCD  information  for  a  Location 

qrvLocationP  rimary  State 

Location_lD 

Assembles  primary  state  information  for  a  Location 

qrvOwner 

Owner_ID 

Joins  owner  type  domain  and  parent-owner  information  to 

owners 

qrv  Owner  Address 

Owner_ID 

Assembles  address  information  applying  only  to  owners 

qrvOwnerPermit 

Owner_ID 

Assembles  permit  information  applying  only  to  owners; 
may  be  crosstabbed 

qrvResource 

Resource_ID 

Joins  resource  type  and  water  body  type  domains  to 
Resources 

qrvRe  source Alias 

Resource_ID 

Assembles  alias  data  applying  only  to  resources;  may  be 
crosstabbed 

qrvResourceDetail 

Resource_ID 

Joins  detail  label  and  data  source  to  resource  details;  may 
be  crosstabbed 

qrvResourceStructure 

Resource_ID 

Assembles  composite  resources  to  show  their  child, 
component  resources 

qrvSite 

SiteJD 

Joins  site  type  and  use  type  domains  to  sites;  also  has 
Owner  JD  and  Location  JD 

qrv  Site  Address 

SiteJD 

Assembles  address  information  applying  only  to  sites 

qrvSiteAlias 

SiteJD 

Assembles  alias  data  applying  only  to  sites;  may  be 
crosstabbed 

qrvSiteDetail 

SiteJD 

Joins  detail  label  and  category,  time  interval,  and  data 
source  to  site  details;  may  be  crosstabbed 

qrvSiteLocationOwnerRe  source 

SiteJD 

A  comprehensive  view  of  sites  constructed  from  four 
separate  views 

qrvSitePermit 

SiteJD 

Assembles  permit  information  applying  only  to  sites;  may 
be  crosstabbed 

qrv  Site  Re  source 

SiteJD 

Joins  views  of  sites  and  resources;  also  has  Resource  JD 

qrvSystem 

SystemJD 

Joins  system  type  domain  to  systems;  also  has  associated 
SiteJD' s 

qrvTransfer 

Transfer JD 

Joins  time  interval  domain  and  volume  view  (default 
values  only)  to  transfers;  also  has  Conveyance  JD 

qrvVolume 

Volume  JD 

Joins  method,  staff,  unit,  and  data  source  domains  to 
volumes;  also  has  Transfer  JD 

qrvVolumeDetail 

Volume  JD 

Joins  detail  label  domain  to  volumes;  may  be  crosstabbed 
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CUSTOMIZING  AND  EXTENDING  THE  DATA  ARCHITECTURE 

NJWaTr  was  designed  to  be  fully  extendable  and  customizable  for  the  specific  needs  of  NJDEP  or 
for  individual  projects.  Two  basic  ways  to  extend  the  database  to  contain  new  data  arc  to  add  fields  or  add 
tables.  In  either  case,  extensions  to  or  customizations  of  the  data  model  should  respect  existing  conventions 
that  apply  to  normalization,  keys  and  relationships,  domain  table  usage,  and  naming  rules.  It  is  recommend¬ 
ed  that  the  names  of  all  custom  accessory  tables  and  fields  be  prefixed  with  the  letter  “z”  or  other  unique 
indicator  to  easily  distinguish  them  from  the  fully  defined,  standard  NJWaTr  objects. 

A  field  could  be  added  to  any  table  where  its  data  can  be  expected  to  be  readily  available  and  regularly 
entered;  however,  fields  should  not  be  added  to  a  working  copy  of  the  database  to  solve  short-term  needs, 
such  as  those  that  facilitate  translating  outside  data  into  the  NJWaTr  format,  or  to  accommodate  an  unusual 
data  inquiry.  Adding  accessory  tables  to  the  structure  is  probably  the  easiest  way  to  extend  the  data  model 
and  can  provide  a  means  to  experiment  with  new  data  elements  without  affecting  the  data  already  stored. 
One-to-zero-or-one  (1:0,1)  relationships  between  existing  and  new  accessory  tables  are  the  equivalent  of 
adding  fields  to  a  table,  but  those  fields  are  physically  stored  in  a  different  place.  Accessory  tables  have  the 
added  advantages  of  allowing  the  new  data  to  be  entered  only  for  those  records  in  the  parent  table  that  need 
them  and  protecting  the  current  data  by  not  altering  existing  structures.  Specialized  accessory  tables  that 
provide  descriptive  fields  for  only  some  members  of  an  existing  table  arc  usually  referred  to  as  subtype 
tables  (Fleming  and  von  Halle,  1989,  p.  90).  For  example,  the  association  table  tadSiteResource  is  a  subtype 
table;  it  contains  Site_IDs  of  only  resource-interactor  Sites  to  pair  with  a  Resource  and  related  domains.  As 
an  additional  example,  to  store  information  specific  to  only  those  Sites  that  arc  drilled  wells,  a  subtype  table 
named  ztblWell  could  be  created  to  contain  fields  for  construction  date,  total  depth,  depth  to  open  interval, 
and  other  details  that  do  not  apply  to  Sites  in  general.  The  PK  of  the  ztblWell  table  would  be  Site_ID  imple¬ 
mented  as  a  FK  from  the  tblSite  table,  and  the  only  entries  in  ztblWell  would  be  for  Sites  (using  their 
Site_ID )  that  arc  drilled  wells  and  for  which  the  user  wants  to  store  the  extra  information.  (Note  that  such 
information  also  could  be  stored  in  the  tadSiteDetail  table  by  creating  the  appropriate  SiteDetailLabel 
values.) 

It  is  expected  that  some  domain  entities  may  better  serve  database  users  if  they  arc  extended  into  more 
complex  domain  structures  through  nesting  or  clustering.  An  indication  that  domain  reevaluation  is  needed 
would  be  when  an  apparent  exception  presents  difficulty  in  selecting  from  a  domain  for  particular  records 
in  the  child  table  or  when  a  domain  provides  too  much  detail  for  grouping  and  sorting  puiposes  (a  higher 
category  domain  is  needed). 

In  addition,  the  data  model  can  be  simplified  by  dropping  fields  from  the  standard  database  because 
they  arc  not  being  used.  That  decision  should  be  based  on  the  value  of  the  data  to  be  stored,  not  on  the  dif¬ 
ficulty  of  obtaining  or  entering  it.  Data  elements  that  arc  discovered  to  be  ambiguous  will  require  reevalu¬ 
ation  to  determine  if  they  should  be  stored  at  all  and  whether  they  arc  being  modeled  and  stored  in  the  correct 
way.  Absence  of  data  for  a  required  field  can  always  be  accommodated  with  a  value  that  represents  an 
absence  condition,  and  nearly  all  of  the  domain  tables  in  NJWaTr  arc  equipped  with  a  record  for  such  use. 

By  linking  to  NJWaTr  from  a  separate  MS  Access  database,  accessory  tables  can  reside  outside  of 
NJWaTr  and  still  be  able  to  use  its  data.  The  database  containing  the  linked  tables  is  often  called  a  front-end 
database,  whereas  the  database  containing  the  actual  tables  and  data  would  then  be  the  back-end.  Finking 
to  NJWaTr  would  be  the  preferred  method  for  preparing  original  import  data  for  inclusion  into  the  NJWaTr 
tables,  where  a  staging  area  front-end  database  is  created  for  the  import  tables  and  original  data  manipula¬ 
tions,  and  new  records  arc  passed  to  the  linked  NJWaTr  tables  only  after  they  have  been  properly  quality- 
assured,  formatted,  and  provided  with  necessary  key  values.  A  staging  database  as  described  can  be 
emptied  and  reused  as  needed  to  process  new  imports. 
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A  front-end  database  is  also  a  good  place  to  create  linkages  to  other  databases.  Links  to  NJWaTr 
tables  would  be  present  along  with  links  to  another  database.  One  or  more  fields  that  contain  identity  infor¬ 
mation  are  required  to  connect  the  data,  and  this  could  be  done  in  a  query  without  altering  either  source 
database.  New  association  tables  also  could  be  created  in  the  front-end  to  pair  corresponding  items  by  their 
key  fields  or  other  identifiers.  For  example,  water-quality  data  could  be  accessible  to  NJWaTr  if  a  water- 
quality  database  used  the  same  SiteName  attribute. 


SUMMARY 

Changing  demographics  and  economic  factors  continue  to  place  additional  demands  on  New  Jersey’s 
finite  water  resources.  Domestic  and  industrial  needs  typically  are  balanced  with  agricultural,  recreational, 
wastewater  discharge,  and  ecological  uses.  These  finite  water  resources  can  be  particularly  stressed  during 
periods  of  drought.  A  key  component  in  managing  the  State’s  water  resources  is  determining  water  avail¬ 
ability. 

To  determine  the  amount  of  water  that  may  be  available  in  a  watershed,  one  must  understand  the 
water  dynamics — the  amount  of  rainfall,  the  amount  and  fate  of  surface-  and  ground-water  withdrawals,  the 
amount  and  location  of  surface-  and  ground-water  discharges,  the  depletive  and  consumptive  uses  of  water, 
the  amount  and  location  of  water  transfers  between  watersheds,  and  the  amount  of  water  that  is  naturally 
leaving  the  watershed  as  stream  flow  and  evapotranspiration.  An  accounting  or  water-budget  model  is 
needed  to  establish  how  much  ground  and  surface  water  might  be  available  in  a  watershed  at  different  times 
and  under  different  use  scenarios.  One  problem  encountered  in  doing  such  analyses  is  the  availability  of 
tools  needed  to  store  and  manipulate  the  water  withdrawal,  use,  and  discharge  data  collected  by  the  State; 
therefore,  a  database  design  was  developed  as  a  tool  to  aid  in  the  analyses. 

The  New  Jersey  Water-Transfer  Data  System  (NJWaTr),  developed  in  cooperation  with  the  New 
Jersey  Department  of  Environmental  Protection,  is  a  database  design  for  the  storage  and  retrieval  of  water- 
use  data  and  is  based  on  a  core  model  developed  for  the  New  England  region.  NJWaTr  can  handle  data  on 
many  facets  of  water  use,  including  (1)  various  types  of  water-use  activities  (withdrawals,  returns,  transfers, 
distributions,  consumptive  use,  wastewater  collection,  and  treatment);  (2)  descriptions,  classifications,  and 
locations  of  places  and  organizations  involved  in  water-use  activities;  (3)  details  of  measured  or  estimated 
volumes  of  water  associated  with  water-use  activities;  and  (4)  information  on  data  sources  and  water 
resources  associated  with  water  use.  NJWaTr  can  be  used  for  large  projects  (states  and  regions)  and  small, 
focused  projects  (watershed  studies). 

The  core  NJWaTr  model  pairs  Sites  to  form  unidirectional  Conveyances,  and  time -bounded  water 
Transfers  arc  stored  for  the  Conveyances.  The  Conveyance-based  model  facilitates  a  water-network 
approach  to  water-use  data  storage,  investigation,  and  visualization.  Information  also  is  stored  about  Loca¬ 
tions,  Owners,  water  Resources,  multi-Site  Systems,  Addresses,  DataSources,  Permits,  Aliases,  and  User- 
Defined  Details. 

Standards  for  normalization,  keys  and  relationships,  indexes,  and  naming  were  applied  to  the  data 
model  and  its  physical  implementation  as  a  stand-alone  MS  Access  database.  The  database  consists  of  76 
tables,  311  fields,  and  95  defined  relationships.  Five  functional  types  of  tables  are  recognized  in  NJWaTr 
and  described.  Domain  tables  constitute  more  than  half  the  tables  and  fields  in  NJWaTr.  The  domains  arc 
pre-populated  with  classification  and  descriptive  terms  and  serve  as  flexible  tools  for  grouping,  sorting,  fil¬ 
tering,  and  summarizing  information.  Operational  considerations  include  index  management,  table  loading 
order,  and  use  of  maintenance  update  queries  and  Views.  NJWaTr  can  be  customized  or  extended  by  adding 
new  fields  and  tables,  by  dropping  existing  fields,  and  by  linking  to  other  databases.  The  data  stored  in 
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NJWaTr  can  be  exported  or  linked  to  other  applications  as  needed,  such  as  for  supply  monitoring,  statistical 
analysis,  and  visualization  using  Geographic  Information  Systems  (GIS). 

NJWaTr  was  designed  for  storage  and  retrieval  of  water-transfer  data  for  New  Jersey.  Domains  can 
be  amended  for  other  areas  and  for  different  major  water-use  patterns.  The  data  contained  in  a  NJWaTr 
database  can  be  transferred  to  other  data-management  tools.  Careful  management  of  the  quality  of  data 
stored  using  the  NJWaTr  structure  will  facilitate  the  use  of  accurate,  complex  investigative  queries  to  assist 
with  management  decisions  about  water  use  and  water  resources,  and  will  help  to  avoid  obsolescence  of  the 
data. 
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Water-Transfer  Data  System  (NJWaTr) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) 


How  to  read  the  Data  Dictionary  listings: 

Each  table  starts  on  a  new  page.  The  top  section  shows  the  table  infonnation: 

Table  Name  is  self-explanatory. 

Table  Description  describes  the  table  contents  or  function. 

Number  of  Fields  in  the  table. 

Number  of  Records  at  the  tune  the  dictionary  was  generated. 

Dependency  -  Full  means  the  table  Primary  Key  (PK)  contains  a  Foreign  Key  (FK) 
field;  Partial  means  the  table  contains  a  required,  non-PK,  FK  field;  Independent 
means  the  table  has  no  FK  fields. 

Loading  Order  -  1  if  there  are  no  incoming  relationships,  2  if  the  table  has  at  least  one 
incoming  relationship  from  a  level  1  table,  3  if  the  table  has  at  least  one  incoming 
relationship  from  a  level  2  table,  and  so  forth. 

Recursive  is  checked  if  the  table  has  a  self-join,  recursive  Foreign  Key  field. 

Below  the  table  section,  each  field  in  the  table  is  listed  along  with  the  definition  infonnation: 

A  number  indicating  the  field  position  within  the  table. 

Field  Name  is  self-explanatory. 

PK  is  checked  if  the  field  is  part  of  the  Primary  Key  for  the  table. 

FK  is  checked  if  the  field  is  a  Foreign  Key— pointing  to  data  in  a  ’parent’  table. 

Rqd  is  checked  if  the  field  is  required  to  have  a  value  for  each  record  in  the  table;  if 
unchecked  the  field  is  optional. 

Type  indicates  the  data  type  of  the  field. 

Size  indicates  the  allowed  number  of  characters  for  Text  fields,  "  for  Memo  fields, 
or  the  number  of  bytes  used  for  storage  for  other  data  types. 

Default  is  the  value  automatically  assigned  to  the  field  if  no  value  is  entered;  it  often 
refers  to  a  foreign  key  value  representing  a  selection  from  a  domain  table. 

Description  of  the  field. 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name  Page 

tadConveyanceDetail  .  1-5 

tadConveyanceExpectedFraction  .  1-6 

tadLocationCounty  .  1-7 

tadLocationHUC  .  1-8 

tadLocationMCD  .  1-9 

tadLocationState  .  1-10 

tadResourceDetail  .  1-11 

tadResourceStructure  .  1-12 

tadSiteConveyance  .  1-13 

tadSiteDetail  .  1-14 

tadSiteResource  .  1-15 

tadSiteUseType  .  1-16 

tadUseConsumedFraction  .  1-17 

tadVolumeDetail  .  1-18 

tasConveyanceAlias  .  1-19 

tasConveyanceOwner  .  1-20 

tasOwnerAddress  .  1-21 

tasOwnerPermit  .  1-22 

tasResourceAlias  .  1-23 

tasSiteAddress  .  1-24 

tasSiteAlias  .  1-25 

tasSitePermit  .  1-26 

tasSiteTypeDetailLabel  .  1-27 

tasSystemSite  .  1-28 

tasWaterBodyDetailLabel  .  1-29 

tblAddress  .  1-30 

tblAlias  .  1-31 

tblConveyance  .  1-32 

tblLocation  .  1-33 

tblOwner  .  1-34 

tblPermit  .  1-35 

tblResource  .  1-36 

tblSite  .  1-37 

tblTransfer  .  1-38 

tblVolume  .  1-39 

tdsAddressType  .  1-40 

tdsConveyanceAction  .  1-41 

tdsConveyanceActionCategory  .  1-42 

tdsConveyanceType  .  1-43 

tdsCounty  .  1-44 

tdsCriticalArea  .  1-45 

tdsCriticalZone  .  1-46 

tdsDroughtRegion  .  1-47 

tdsHUC  .  1-48 

tdsLocationScale  .  1-49 

tdsMCD  .  1-50 

tdsOwnerType  .  1-51 

tdsPermitSeries  .  1-52 

tdsResourceType  .  1-53 

tdsSiteType  .  1-54 

tdsSiteTypeCategory  .  1-55 

tdsSiteTypeSubcategory  .  1-56 

tdsState  .  1-57 


1-3 


Appendix  1 :  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name  Page 

tdsTimelnterval  .  1-58 

tdsUseGroup  .  1-59 

tdsUseType  .  1-60 

tdsVolumeUnitDecimal  .  1-61 

tdsVolumeUnitQuantity  .  1-62 

tdsWaterBodyType  .  1-63 

tdsWaterMgmntArea  .  1-64 

tdsWaterRegion  .  1-65 

tdxAliasLabel  .  1-66 

tdxConveyanceDetailLabel  .  1-67 

tdxDataSource  .  1-68 

tdxLocationDetMethod  .  1-69 

tdxPermitLabel  .  1-70 

tdxResourceDetailLabel  .  1-71 

tdxSiteDetailCategory  .  1-72 

tdxSiteDetailLabel  .  1-73 

tdxStaff  .  1-74 

tdxSystem  .  1-75 

tdxSystemType  .  1-76 

tdxVolumeDetailLabel  .  1-77 

tdxVolumeMethod  .  1-78 

tdxVolumeMethodCategory  .  1-79 

tdxVolumeUnit  .  1-80 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  Conveyance_ID  0  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Conveyance 

2  ConveyanceDetailLabel_ID  0  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Conveyance 
Detail  Label 

3  ConveyanceDetail  0  0  0  Text  50  Conveyance  Detail 

information  (numeric  or 
textual  value) 
corresponding  to  the 
ConveyanceDetailLabel 
descriptor 

Note  about  a 
Conveyance  Detail 


4  ConveyanceDetailMemo  O  O  O  Memo 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tadConveyanceExpectedFraction 


Table  Description: 


Fraction  of  originating  Sites'  available  water  (not  consumed)  expected  by  a 
receiving  Site  on  a  Conveyance  for  a  specified  time  period 


Number  of  Fields:  4  Dependency:  Full  Recursive:  □ 

Number  of  Records  0  Loading  Order:  4 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  Conveyance_ID  0  0  0  Long  Integer  4 

2  ExpectedFractionEffectiveDate  0  dl  0  DateTime  8 


3  ExpectedFractionEndingDate  dl  dl  dl  DateTime  8 


4  ExpectedFraction 


□  □  0  Single  4 


Key  that  uniquely 
identifies  a  Conveyance 

Effective  Date  for  which  a 
Transfer  Expected 
Fraction  amount  applies; 
changes  to  expected 
amounts  are  managed  by 
new  Effective  Date 
entries  with  the  new 
amount 

Ending  Date  for  which  a 
Percent  Transfer 
Expected  amount  applies; 
is  Null  while  expected 
amount  is  still  in  effect 

Fraction  of  originating 
Sites'  available  water 
expected  by  a  receiving 
Site  on  a  Conveyance;  in 
decimal  units,  where  100 
percent  is  entered  as  1.0 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tadLocationCounty 

Table  Description:  Association  of  a  proportion  of  a  Location  with  a  County 

Dependency:  Full  Recursive:  □ 


Number  of  Fields:  4 

Number  of  Records  1 


Full 

Loading  Order:  3 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  LocationID 

2  CountylD 


3  CountyFraction 


4  IsPrimaryCounty 


0  0  0  Long  Integer  4 


Key  that  uniquely 
identifies  a  Location 


0  0  0  Integer  2 

□  □  0  Single  4 


□  □  □  Yes/No  1 


Key  that  uniquely 
identifies  a  State/County 
combination 

Fraction  of  the  Location 
that  is  in  the  County;  in 
decimal  units,  where  100 
percent  is  entered  as  1 .0 

Identifies  a  primary 
County  to  be  associated 
with  a  Location  when 
more  than  one  may  be 
associated;  when  more 
than  one,  one  is 
designated  'Yes'  (the 
primary)  and  the  others 
'No';  for  singular 
Location-County 
associations,  the  value  is 
always  'Yes' 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 

Number  of  Fields: 
Number  of  Records 


tadLocationHUC 

Association  of  a  proportion  of  a  Location  with  a  Hydrologic  Unit 

4  Dependency:  Full  Recursive:  □ 

1  Loading  Order:  4 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  LocationID 

2  HUC  ID 


3  HUCFraction 


4  IsPrimaryHUC 


0  0  0  Long  Integer  4 


Key  that  uniquely 
identifies  a  Location 


0  0  0  Integer  2 

□  □  0  Single  4 


□  □  □  Yes/No  1 


Key  that  uniquely 
identifies  a  Hydrologic 
Unit 

Fraction  of  the  Location 
that  is  in  the  HUC;  in 
decimal  units,  where  100 
percent  is  entered  as  1 .0 

Identifies  a  primary  HUC 
to  be  associated  with  a 
Location  when  more  than 
one  may  be  associated; 
when  more  than  one,  one 
is  designated  'Yes'  (the 
primary)  and  the  others 
'No';  for  singular 
Location-HUC 
associations,  the  value  is 
always  'Yes' 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 


tadLocationMCD 


Table  Description:  Association  of  a  proportion  of  a  Location  with  a  Minor  Civil  Division 

Number  of  Fields:  4  Dependency:  Full  Recursive:  □ 

Number  of  Records  1  Loading  Order:  4 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  LocationID 

2  MCDID 


3  MCDFraction 


4  IsPrimaryMCD 


0  0  0  Long  Integer  4 


Key  that  uniquely 
identifies  a  Location 


0  0  0  Integer  2 


□  □  0  Single  4 


□  □  □  Yes/No  1 


Key  that  uniquely 
identifies  a  MCD  (Minor 
Civil  Division  of  US 
Census  Bureau) 

Fraction  of  the  Location 
that  is  in  the  MCD;  in 
decimal  units,  where  100 
percent  is  entered  as  1.0 

Identifies  a  primary  MCD 
to  be  associated  with  a 
Location  when  more  than 
one  may  be  associated; 
when  more  than  one,  one 
is  designated  'Yes'  (the 
primary)  and  the  others 
'No';  for  singular 
Location-MCD 
associations,  the  value  is 
always  'Yes' 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tadLocationState 

Table  Description: 

Association  of  a  proportion  of  a  Location  with  a  State 

Number  of  Fields: 

4 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

1 

Loading  Order:  3 

Field  Name 

PK  FK  Rqd 

Type 

Size  Default 

Description 

1  Location  ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Location 

2  State  ID 

0  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  State  or 
Canadian  Province 

3  StateFraction 

□  □  0 

Single 

4 

Fraction  of  the  Location 
that  is  in  the  State;  in 
decimal  units,  where  100 
percent  is  entered  as  1.0 

4  IsPrimaryState 

□  □  □ 

Yes/No 

1 

Identifies  a  primary  State 
to  be  associated  with  a 
Location  when  more  than 
one  may  be  associated; 
when  more  than  one,  one 
is  designated  'Yes'  (the 
primary)  and  the  others 
'No';  for  singular 
Location-State 
associations,  the  value  is 
always  'Yes' 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 


tadResourceDetail 


Number  of  Fields: 
Number  of  Records  0 


User-defined  Detail  about  a  Resource  (time-dependent) 

7  Dependency:  Full  Recursive:  □ 

Loading  Order:  4 


Field  Name  PK  FK  Rqd  Type  Size  Default  Description 


ResourcelD 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  water 

Resource 

ResourceDetailLabel  ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Resource 
Detail  Label 

ResourceDetailEffectiveDate 

0  □  0 

DateTime 

8 

Effective  (starting)  date 
for  a  recorded  Resource 
Detail  (lower  bound  of 
time  interval) 

ResourceDetailEndingDate 

□  □  □ 

DateTime 

8 

Ending  date  for  a 
recorded  Resource  Detail 
(upper  bound  of  time 
interval);  is  Null  while 
Detail  is  still  in  effect 

DataSource  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Data  Source 

ResourceDetail 

□  □  0 

Text 

50 

Resource  Detail 
information  (numeric  or 
textual  value) 
corresponding  to  the 
ResourceDetailLabel 
descriptor 

ResourceDetailMemo 

□  □  □ 

Memo 

- 

Note  about  a  Resource 
Detail 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tadResourceStructure 

Table  Description:  Association  of  a  single  composite  Resource  with  subparts  defined  by  other 
Resources 

Number  of  Fields:  4  Dependency:  Full  Recursive:  □ 

Number  of  Records  0  Loading  Order:  4 

Field  Name 

PK  FK  Rqd  Type 

Size 

Default 

Description 

1  ParentResource  ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 
identifies  a  water 

Resource 

2  ChildResource  ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 
identifies  a  water 

Resource 

3  ParentResourceFraction 

□  □  □  Single 

4 

Fraction  of  Parent 

Resource  represented  by 
the  Child  Resource;  in 
decimal  units,  where  100 
percent  is  entered  as  1 .0 

4  IsPrimaryResource 

□  □  □  Yes/No 

1 

No 

Identifies  a  primary 

Resource  to  be 
associated  with  a 
combined  Resource;  one 
may  be  designated  'Yes' 
(the  primary)  and  the 
other(s)  'No' 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  Conveyance_ID 

2  FromOrTo 

3  Site  ID 


0  0  0  Long  Integer  4 

0  O  0  Text  4 

D  0  0  Long  Integer  4 


Key  that  uniquely 
identifies  a  Conveyance 

Identifies  an  individual 
Site  as  the  Input  (From) 
or  Output  (To)  end  of  a 
specific  Conveyance 

Key  that  uniquely 
identifies  a  Site 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tadSiteDetail 

Table  Description:  User-defined  Detail  about  a  Site  (time-dependent) 


Number  of  Fields:  8 
Number  of  Records  0 


Dependency:  Full 

Loading  Order:  5 


Recursive:  □ 


Field  Name  PK  FK  Rqd  Type  Size  Default  Description 


Site_ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 

SiteDetailLabel  ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site  Detail 
Label 

S  iteDetailEffecti  veDate 

0  □  0 

DateTime 

8 

Effective  (starting)  date 
for  a  recorded  Site  Detail 
(lower  bound  of  time 
interval) 

SiteDetailEndingDate 

□  □  □ 

DateTime 

8 

Ending  date  for  a 
recorded  Site  Detail 
(upper  bound  of  time 
interval);  is  Null  while 
Detail  is  still  in  effect 

DataSource  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Data  Source 

Timelnterval  ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Time  Interval 

SiteDetailValue 

□  □  0 

Text 

50 

Site  Detail  information 
(numeric  or  textual  value) 
corresponding  to  the 
SiteDetailLabel  descriptor 

SiteDetailMemo 

□  □  □ 

Memo 

— 

Note  about  a  Site  Detail 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tadSiteResource 

Table  Description:  Association  of  a  Site  with  a  water  Resource 


Number  of  Fields:  5 
Number  of  Records  0 


Dependency:  Full 

Loading  Order:  5 


Recursive:  □ 


1 

2 


3 

4 

5 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default 

Description 

Site_ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 

ResourcelD 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  water 

Resource 

CriticalArea  ID 

□  0  0 

Integer 

2 

0 

Key  that  uniquely 
identifies  a  Critical  Area 

CriticalZone  ID 

□  0  0 

Integer 

2 

0 

Key  that  uniquely 
identifies  a  Critical  Zone 

ConnectionCount 

□  □  □ 

Integer 

2 

Number  of  direct 
Connections  represented 
by  the  association  of  a 

Site  with  a  water  Resource 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tadSiteUseType 

Table  Description: 

Association  of  a  multi-use  Site  with  a  UseType  and  its  fraction  of  the  total 

Use 

Number  of  Fields: 

Number  of  Records 

3 

0 

Dependency:  Full 

Loading  Order:  5 

Recursive:  □ 

Field  Name 

PK  FK  Rqd  Type 

Size 

Default  Description 

1  Site_ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 

2  UseType_ID 

0  0  0  Integer 

2 

Key  that  uniquely 
identifies  a  Water  Use 

Type  classification  for  a 

Site 

3  UseTypeFraction 

□  □  □  Single 

4 

Fraction  of  total  Use  for  a 

multi-use  Site  represented 
by  an  individual 
UseType;  in  decimal 
units,  where  100  percent 
is  entered  as  1 .0 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tadUseConsumedF  raction 

Table  Description: 

Association  of  a  UseType  with  monthly  estimates  of  the  fraction  of 
available  water  that  is  consumed 

Number  of  Fields: 

3 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

12 

Loading  Order:  3 

Field  Name 

PK  FK  Rqd  Type 

Size 

Default  Description 

1  UseType_ID 

0  0  0  Integer 

2 

Key  that  uniquely 
identifies  a  Water  Use 

Type  classification  for  a 

Site 

2  Month 

0  □  0  Long  Integer 

4 

Month  of  the  year,  in 

Integer  format  ( Jan  =  1 , 

Feb  =  2,  and  so  forth) 

3  ConsumedFraction 

□  □  0  Single 

4 

Fraction  of  the  UseType 

water  that  is  consumed  in 
a  given  Month;  in 
decimal  units,  where  100 
percent  is  entered  as  1 .0 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tadVolumeDetail 

Table  Description: 

User-defined  Detail  about  a  Transfer  Volume 

Number  of  Fields: 

4 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  6 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  Volume  ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 

identifies  a  Volume  for  a 
Transfer 


2  VolumeDetailLabel_ID  0  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Volume  Detail 
Label 


3  VolumeDetail 


□  □  0  Text 


4  VolumeDetailMemo 


□  D  D  Memo 


50  Volume  Detail  information 

(numeric  or  textual  value) 
corresponding  to  the 
VolumeDetailLabel 
descriptor 

Note  about  a  Volume 
Detail 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tasConveyanceAlias 

Table  Description: 

Association  of  a  Conveyance  with  an  Alias 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  6 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

1  Conveyance  ID 

0 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Conveyance 

2  Alias  ID 

0 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Alias 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tasConveyanceOwner 

Table  Description: 

Association  of  a  Conveyance  with  an  Owner 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  4 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

1  Conveyance  ID 

0  0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Conveyance 

2  Owner  ID 

0  0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Owner 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tasOwnerAddress 

Table  Description: 

Association  of  an  Owner  with  an  Address 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  3 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

Owner  ID 

0 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Owner 

Address_ID 

0 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Address 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 

tasOwnerPermit 

Association  of  an  Owner  with  a  Permit 

Number  of  Fields: 

2 

Dependency: 

Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order: 

6 

Field  Name 

PK  FK  Rqd  Type 

Size 

Default  Description 

Owner  ID 

0  0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Owner 

PermitID 

0  0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Permit 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tasResourceAlias 

Table  Description: 

Association  of  a  water  Resource  with  an  Alias 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  6 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  Resource  ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 
identifies  a  water 

Resource 

2  Alias  ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 

identifies  an  Alias 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tasSiteAddress 

Table  Description: 

Association  of  a  Site  with  an  Address 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  5 

Field  Name 

PK  FK  Rqd  Type 

Size 

Default  Description 

1  Site_ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 

2  Address_ID 

0  0  0  Long  Integer 

4 

Key  that  uniquely 

identifies  an  Address 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tasSiteAlias 

Table  Description:  Association  of  a  Site  with  an  Alias 

Number  of  Fields:  2  Dependency:  Full  Recursive:  □ 

Number  of  Records  0  Loading  Order:  6 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1  Site_ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 

2  Alias  ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Alias 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tasSitePermit 

Table  Description: 

Association  of  a  Site  with  a  Permit 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  6 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

Site_ID 

0  0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 

PermitID 

0  0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Permit 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  SiteDetailLabel  ID 

0  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site  Detail 
Label 

2  SiteType_ID 

0  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Site  Type 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tas  System  Site 

Table  Description: 

Association  of  a  Site  with  a  named  System 

Number  of  Fields: 

2 

Dependency:  Full 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  5 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

1  System  ID 

0 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  System 

2  Site_ID 

0 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Site 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  WaterBodyType_ID  0  0  0  Integer  2  Key  that  uniquely 

identifies  a  Type  of 
Water  Body  represented 
by  a  water  Resource  (for 
example,  lake,  river, 
estuary) 

2  ResourceDetailLabel_ID  0  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Resource 
Detail  Label 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tblAddress 

Table  Description: 

Address  information  for  an  Owner  or  Site 

Number  of  Fields: 

9 

Dependency: 

Partial 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order: 

2 

Field  Name 

PK  FK  Rqd 

Type 

Size 

Default 

Description 

1  Address_ID 

0 

□ 

0 

AutoNumber 

4 

Key  that  uniquely 

(Long) 

identifies  an  Address 

2  AddressType_ID 

□ 

0 

0 

Integer 

2 

Key  that  uniquely 
identifies  an  Address 

Type 

3  AddressLinel 

□ 

□ 

□ 

Text 

50 

Address  Line  1 

4  AddressLine2 

□ 

□ 

□ 

Text 

50 

Address  Line  2 

5  City 

□ 

□ 

0 

Text 

50 

City  Name 

6  StateAbbrv 

□ 

□ 

0 

Text 

2 

State  (or  Canadian 

Province)  Abbreviation 

7  ZipCode 

□ 

□ 

□ 

Text 

10 

Postal  Zip  Code 

8  CountryAbbrv 

□ 

n 

0 

Text 

3 

"USA" 

Country  Abbreviation 
(USA  or  CAN) 

9  AddressMemo 

□ 

□ 

□ 

Memo 

— 

Note  about  an  Address 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tblAIias 

Table  Description: 

Alias,  such  as  a  local  or  Federal  ID  code,  for  a  Site,  Conveyance  or  water 
Resource 

Number  of  Fields: 

4 

Dependency:  Partial 

Recursive:  □ 

Number  of  Records 

0 

Loading  Order:  5 

Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1  AliasID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  an  Alias 

2  AliasLabel  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  AliasLabel 

3  AliasValue 

□  □  0 

Text 

50 

Alias  Value,  such  as  a 
Station  ID 

4  AliasMemo 

□  □  □ 

Memo 

_ 

Note  about  an  Alias 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  Conveyance_ID  0  0  0  AutoNumber  4  Key  that  uniquely 

(Long)  identifies  a  Conveyance 

2  ConveyanceType_ID  0  0  0  Integer  2  Key  that  uniquely 

identifies  a  Conveyance 
Type 

3  ConveyanceAction_ID  0  0  0  Integer  2  Key  that  uniquely 

identifies  an  Action 
performed  by  a 
Conveyance  between  two 
Sites 

4  ConveyanceName  0  0  0  Text  200  Name  of  Conveyance 

5  ConveyanceMemo  0  0  0  Memo  —  Note  about  a  Conveyance 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tblLocation 

Table  Description:  Location  information  for  a  Site,  including  scale,  coordinates,  and 
association  with  geopolitical  and  hydrologic  areas 

Number  of  Fields:  9  Dependency:  Partial  Recursive:  EH 

Number  of  Records  1  Loading  Order:  2 

Field  Name 

PK  FK  Rqd 

Type 

Size  Default 

Description 

1  Location  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Location 

2  LocationDetMethod  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Location 
Determination  Method 

3  LocationScale  ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  spatial  Scale 
term  for  a  Location 

4  LocationName 

□  □  □ 

Text 

200 

Location  Name 

5  LocationLatitude 

□  □  □ 

Text 

30 

Latitude  coordinate 
(DMS  format)  for  a 

Location 

6  LocationLongitude 

□  □  □ 

Text 

30 

Longitude  coordinate 
(DMS  format)  for  a 

Location 

7  NJEasting 

□  □  □ 

Text 

50 

New  Jersey  system  East 
coordinate 

8  NJNorthing 

□  □  □ 

Text 

50 

New  Jersey  system  North 
coordinate 

9  LocationMemo 

□  □  □ 

Memo 

— 

Note  about  a  Location 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  OwnerlD  0  n  0  AutoNumber  4  Key  that  uniquely 

(Long)  identifies  an  Owner 

2  OwnerType_ID  0  0  0  Integer  2  Key  that  uniquely 

identifies  an  Owner  Type 

3  ParentOwner_ID  0  0  0  Long  Integer  4  Key  that  uniquely 

identifies  the  Parent- 
Owner  of  the  current 
Owner,  for  example  a 
regional  organization 

4  OwnerName  0  0  0  Text  200  OwnerName 

5  OwnerContact  0  0  0  Text  200  Contact  Name  for  an 

Owner 

6  OwnerPhone  0  0  0  Text  25  Contact  Phone  number 

for  an  Owner 

7  OwnerMemo  0  0  0  Memo  —  Note  about  an  Owner 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tblPermit 

Table  Description: 

Permit,  such  as  PWSID  or  BWA,  assigned  to 
permitting  agency 

a  Site  or  Owner  by  a 

Number  of  Fields: 

Number  of  Records 

5  Dependency: 

0  Loading  Order: 

Partial 

5 

Recursive:  □ 

Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1  PermitID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Permit 

2  PermitLabel  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Permit  Label 

3  PermitSeries  ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Permit  Series 

4  PermitNumber 

□  □  0 

Text 

50 

Code  or  Number  of  a 
specific  Permit 

5  PermitMemo 

□  □  □ 

Memo 

— 

Memo  about  a  Permit 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tblResource 


Table  Description:  Water  Resource  involved  in  water-use  activities  (withdrawals,  transfers, 
and  returns);  includes  aquifers,  springs,  streams  and  rivers,  lakes  and 
reservoirs,  estuaries  and  embayments,  and  the  ocean 


Number  of  Fields:  6  Dependency:  Partial  Recursive:  EH 

Number  of  Records  1  Loading  Order:  3 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  Resource  ID 


2  WaterBodyTypelD 


3  OwnerlD 

4  ResourceName 


5  ResourceCodeName 


6  ResourceMemo 


0  n  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  water 

Resource 

□  00 

Integer 

2 

Key  that  uniquely 
identifies  a  Type  of 

Water  Body  represented 
by  a  water  Resource  (for 
example,  lake,  river, 
estuary) 

□  00 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Owner 

□  □  0 

Text 

200 

Name  typically  used  to 
identify  a  specific  water 
Resource  (for  example, 
'Mill  Creek'  or  'Spruce 

Run  Reservoir') 

□  □  □ 

Text 

200 

Code-Name  phrase  used 
to  uniquely  identify  a 
Resource  to  distinguish  it 
from  others  having  the 
same  ResourceName  (for 
example,  'Mill  Creek, 
Wildwood  Crest,  NJ' 
versus  'Mill  Creek,  Ocean 
City,  NJ') 

□  □  □ 

Memo 

- 

Note  about  a  water 

Resource 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tblSite 

Table  Description:  Site  involved  in  water-use  activities;  includes  wells,  intakes  and  outfalls, 
distribution  and  treatment  facilities,  collection  systems,  industrial, 
commercial  and  domestic  users,  and  aggregate-use  entities 

Number  of  Fields:  8  Dependency:  Partial  Recursive:  EH 

Number  of  Records  3  Loading  Order:  4 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1 

Site_ID 

0EI0 

AutoNumber 

4 

Key  that  uniquely 

(Long) 

identifies  a  Site 

2 

Location  ID 

□  00 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Location 

3 

Owner  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Owner 

4 

SiteTypelD 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Site  Type 

5 

UseType_ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Water  Use 

Type  classification  for  a 
Site 

6 

SiteName 

□  □  0 

Text 

100 

Site  Name 

7 

SiteContact 

□  □  □ 

Memo 

-- 

Site  Contact  Information 

8 

SiteMemo 

□  □  □ 

Memo 

— 

Note  about  a  Site 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 


tblTransfer 

Record  of  a  water  Transfer  through  a  Conveyance  between  two  Sites  for  a 
specified  Time  Interval 


Number  of  Fields:  7 
Number  of  Records  0 


Dependency:  Partial 

Loading  Order:  4 


Recursive:  □ 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  Transfer_ID 

2  Conveyance® 

3  TimeInterval_ID 

4  TransferEffectiveDate 

5  TransferEndingDate 

6  VolumeMG 


BOB  AutoNumber  4 

(Long) 

□  00  Long  Integer  4 

□  00  Integer  2 

□  □  0  DateTime  8 

□  □  0  DateTime  8 

□  □  0  Double  8 


7  TransferMemo 


□  □  □  Memo 


Key  that  uniquely 
identifies  a  Transfer 

Key  that  uniquely 
identifies  a  Conveyance 

Key  that  uniquely 
identifies  a  Time  Interval 

Effective  (starting)  date 
for  a  Transfer  record 
(lower  bound  of  time 
interval) 

Ending  date  for  a 
Transfer  record  (upper 
bound  of  time  interval) 

Volume  value  for  the 
Transfer  in  million  gallon 
units;  a  derived  value 
representing  the  product 
of  the  default 
RawVolumeValue  for  the 
Transfer  and  the 
CommonConversion 
factor  to  convert  to 
million  gallon  common 
units. 

Note  about  a  Transfer 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  Volume_ID  0  0  0  AutoNumber  4  Key  that  uniquely 

(Long)  identifies  a  Volume  for  a 

Transfer 

2  Transfer_ID  O  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Transfer 

3  Staff_ID  D  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Staff  person 

4  DataSource_ID  D  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Data  Source 

5  VolumeMethod_ID  Q  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Method  used 
to  determine  the  Volume 
of  a  Transfer 

6  RawVolumeValue  □  □  0  Double  8  Numeric  part  of  the  Raw 

Volume  Value  for  a 
Transfer 

7  VolumeUnit_ID  D  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Volume  Unit 
(units  by  which  raw 
Volume  values  are 
originally  recorded  or 
estimated)  for  a  Transfer 

8  IsDefaultVolume  O  O  0  Yes/No  1  Yes  Identifies  a  default 

Volume  to  be  associated 
with  a  Transfer;  'Yes' 
when  only  one  Volume  is 
associated,  or  for  one 
Volume  among 
alternatives;  when  'No',  at 
least  one  additional 
Volume  exists  as  the 
default 

9  VolumeMemo  O  O  O  Memo  —  Note  about  a  Volume 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsAddressType 

Table  Description: 

List  of  Types  of  Addresses  associated  with  a 

Site  or  an  Owner 

Number  of  Fields: 

2 

Dependency:  Independent 

Recursive:  □ 

Number  of  Records 

3 

Loading  Order:  1 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

1  AddressType_ID 

0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  an  Address 
Type 

2  AddressType 

□  □  0 

Text 

20 

Type  of  Address  (street, 
mailing,  both) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 

Number  of  Fields: 
Number  of  Records 


tdsConveyanceAction 

List  of  Actions  performed  by  a  Conveyance  between  two  Sites 

Dependency:  Partial  Recursive:  □ 


5 

180 


Partial 
Loading  Order:  2 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  ConveyanceAction_ID  0  □  0  Integer  2 


2  ConveyanceActionCategory_ID  D  0  0  Integer  2 


3  ConveyanceActionPhrase  0  0  0  Text  75 


4  SiteTypeFromID 


O  O  0  Integer  2 


5  SiteTypeToID 


O  O  0  Integer  2 


Key  that  uniquely 
identifies  an  Action 
performed  by  a 
Conveyance  between  two 
Sites 

Key  that  uniquely 
identifies  a  Category  of 
an  Action  performed  by  a 
Conveyance  between  two 
Sites 

Phrase  that  describes  the 
particular  Action 
performed  by  a 
Conveyance 

Key  that  identifies  the 
SiteType  on  the  'From' 
side  of  a  Conveyance  for 
a  particular  Action 
between  two  Sites 

Key  that  identifies  the 
SiteType  on  the  'To'  side 
of  a  Conveyance  for  a 
particular  Action  between 
two  Sites 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  ConveyanceActionCategory_ID  0  O  0  Integer  2  Key  that  uniquely 

identifies  a  Category  of 
an  Action  performed  by  a 
Conveyance  between  two 
Sites 

2  ConveyanceActionCategory  0  0  0  Text  50  Term  that  defines  a 

Category  of  an  Action 
performed  by  a 
Conveyance  between  two 
Sites 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsConveyanceType 

Table  Description:  List  of  Types  of  Conveyances 

Number  of  Fields:  3 

Number  of  Records  7 

Dependency: 
Loading  Order: 

Independent 

1 

Recursive:  □ 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  ConveyanceType  ID 

0  □  0  Integer 

2 

Key  that  uniquely 
identifies  a  Conveyance 
Type 

2  ConveyanceType 

□  □  0  Text 

20 

Type  of  Conveyance  (for 
example,  pipe,  canal, 
conduit,  and  others) 

3  ConveyanceTypeMemo 

□  □  □  Memo 

— 

Note  about  a 

Conveyance  Type 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  County_ID  0  □  @  Integer  2  Key  that  uniquely 

identifies  a  State/County 
combination 

2  State_ID  EH  0  0  Integer  2  Key  that  uniquely 

identifies  a  State  or 
Canadian  Province 

3  StateCountyCode  EH  EH  0  Text  5  Concatenation  of  State 

and  County  Code 
numbers  (unique) 

4  CountyCode  EH  EH  0  Text  3  County  Code  number 

within  a  State 


5  CountyName  EH  EH  0  Text 

6  County ShortName  EH  EH  0  Text 

7  CountyLatitude  0  EH  0  Text 

8  CountyLongitude  EH  EH  0  Text 


50  County  Name 

50  County  Name  without  the 

word  'County'  or  'Parish' 

30  Latitude  coordinate 

(decimal  degrees  format) 
for  the  centroid  of  a 
County 

30  Longitude  coordinate 

(decimal  degrees  format) 
for  the  centroid  of  a 
County 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsCriticalArea 

Table  Description:  List  of  New  Jersey  Critical  Areas  developed  for  conservation  management 
of  regulated  aquifers 

Number  of  Fields:  3  Dependency:  Independent  Recursive:  □ 

Number  of  Records  4  Loading  Order:  1 


Field  Name 

1  CriticalArealD 

2  CriticalAreaCode 

3  CriticalArea 


PK  FK  Rqd 

Type 

Size 

Default  Description 

0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Critical  Area 

□  □  0 

Text 

5 

Code  that  uniquely 
identifies  a  Critical  Area 

□  □  0 

Text 

255 

Critical  Area  description 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsCriticaIZone 

Table  Description: 

List  of  New  Jersey  Critical  Zone  classifications  used  to  identify  Sites  in 

threatened  or  depleted  zones  of  regulated  aquifers 

Number  of  Fields: 

3 

Dependency:  Independent 

Recursive:  □ 

Number  of  Records 

7 

Loading  Order:  1 

Field  Name 

PKFKRqd  Type  Size  Default 

Description 

CriticalZone  ID 

0 

□ 

0 

Integer 

2 

Key  that  uniquely 
identifies  a  Critical  Zone 

CriticaIZoneCode 

□ 

□ 

0 

Text 

5 

Code  that  uniquely 
identifies  a  Critical  Zone 

CriticalZone 

□ 

□ 

0 

Text 

255 

Critical  Zone  description 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  DroughtRegion_ID  0  □  @  Integer  2  Key  that  uniquely 

identifies  a  Drought 
Region 

2  DroughtRegionCode  D  D  0  Text  5  Code  that  uniquely 

identifies  a  Drought 
Region 

3  DroughtRegion  □  □  0  Text  50  Drought  Region  name 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsHUC 


Table  Description: 

Number  of  Fields: 
Number  of  Records 


List  of  Hydrologic  Unit  Codes  (HUCs)  and  associated  information 

9  Dependency:  Partial  Recursive:  □ 

934  Loading  Order:  3 


Field  Name  PK  FK  Rqd  Type  Size  Default  Description 


HUCID 

0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Hydrologic 
Unit 

WaterMgmntArea  ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  New  Jersey 
Water  Management  Area 

WatershedCode 

□  □  0 

Text 

20 

New  Jersey  Watershed 
Code  for  a  14-digit 
hydrologic  unit 

HUC14 

□  □  0 

Text 

14 

Hydrologic  Unit  14-digit 
Code  from  national  list 

HUC14Name 

□  □  0 

Text 

50 

Name,  if  available,  of  14- 
digit  Hydrologic  Unit 
(USGS  names) 

HUC11 

□  □  0 

Text 

11 

Hydrologic  Unit  1 1 -digit 
Code  from  national  list 

HUCllName 

□  □  □ 

Text 

50 

Name,  if  available,  of  1 1- 
digit  Hydrologic  Unit 
(NJDEP  names) 

HUC8 

□  □  0 

Text 

8 

Hydrologic  Unit  8-digit 
Code  from  national  list 

HUC8Name 

□  □  □ 

Text 

50 

Name,  if  available,  of  8- 
digit  Hydrologic  Unit 
(USGS  names) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 

Number  of  Fields: 
Number  of  Records 


tdsLocationScale 

List  of  Scale  terms  (point,  MCD,  County,  and  others)  that  describe  the 
spatial  extent  of  a  Location 


Dependency:  Independent 

Loading  Order:  1 


Recursive:  □ 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1  LocationScale  ID 

0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  spatial  Scale 
term  for  a  Location 

2  LocationScale 

□  □  0 

Text 

50 

Term  that  describes  the 
spatial  Scale  of  a 

Location  (for  example, 
point,  MCD,  County, 

State,  HUC,  and  others) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsMCD 


Table  Description: 


List  of  Minor  Civil  Divisions  (MCDs  or  Subcounty  divisions)  of  the  US 
Census  Bureau 


Number  of  Fields:  10  Dependency:  Partial  Recursive:  EH 

Number  of  Records  4,479  Loading  Order:  3 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  MCDID 


2  CountylD 


3  DroughtRegion_ID 


4  StateMCDCode 


5  MCDCode 

6  MCDType 


7  MCDName 

8  MCDShortName 


9  MCDLatitude 


10  MCDLongitude 


0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  MCD  (Minor 
Civil  Division  of  US 
Census  Bureau) 

□  00 

Integer 

2 

Key  that  uniquely 
identifies  a  State/County 
combination 

□  00 

Integer 

2 

Key  that  uniquely 
identifies  a  Drought 
Region 

□  □  0 

Text 

7 

Concatenation  of  State 
and  MCD  Code  numbers 
(unique  within  a  County) 

□  □  0 

Text 

5 

MCD  Code  within  a  State 

□  □  0 

Text 

20 

Type  of  MCD  (for 
example,  town,  city, 
plantation,  reservation, 
and  others) 

□  □  0 

Text 

50 

MCD  Name 

□  □  0 

Text 

50 

Short  name  for  MCD 
(excludes  MCD  type, 
which  is  part  of  formal 
Census  MCD  name) 

□  □  0 

Text 

30 

Latitude  coordinate 
(decimal  degrees  format) 
for  the  centroid  of  a  MCD 

□  □  0 

Text 

30 

Longitude  coordinate 
(decimal  degrees  format) 
for  the  centroid  of  a  MCD 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsOwnerType 

Table  Description: 

List  of  Types  of  Owners 

Number  of  Fields: 

3 

Dependency: 

Independent 

Recursive:  □ 

Number  of  Records 

7 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  OwnerType  ID 

0  □  0  Integer 

2 

Key  that  uniquely 
identifies  an  Owner  Type 

2  OwnerType 

□  □  0  Text 

25 

Type  of  Owner  (for 
example,  federal,  state, 
municipal,  private,  and 
others) 

3  OwnerTypeMemo 

□  □  □  Memo 

— 

Note  about  an  Owner 

Type 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsPermitSeries 

Table  Description: 

List  of  Series  groupings  for  Permits 

Number  of  Fields: 

3 

Dependency:  Independent 

Recursive:  □ 

Number  of  Records 

10 

Loading  Order:  1 

Field  Name 

PKFKRqd  Type  Size  Default 

Description 

PermitSeries  ID 

0 

□ 

0 

Integer 

2 

Key  that  uniquely 
identifies  a  Permit  Series 

PermitSeries 

□ 

n 

0 

Text 

50 

Series  grouping  for 

Permits 

PermitSeriesDescription 

□ 

□ 

0 

Text 

120 

Description  of  a  Series 
grouping  for  Permits 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsResourceType 

Table  Description:  List  of  Types  of  water  Resources 

Number  of  Fields:  4 

Number  of  Records  7 

Dependency: 
Loading  Order: 

Independent 

1 

Recursive:  □ 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  ResourceType_ID 

0  □  0  Integer 

2 

Key  that  uniquely 
identifies  a  water 

Resource  Type 

2  GWorSW 

□  □  0  Text 

2 

GW  (ground  water)  or 

SW  (surface  water) 
identifier  for  a 

ResourceType 

3  Salinity 

□  □  0  Text 

2 

Salinity  group  of  a 
ResourceType  (fresh, 
brackish  or  saline) 

4  ResourceType 

□  □  0  Text 

50 

Type  of  water  Resource 

(for  example,  fresh 
ground-water,  brackish 
surface-water,  and  others) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  SiteType_ID  0  □  @  Integer  2  Key  that  uniquely 

identifies  a  Site  Type 

2  SiteTypeSubcategory_ID  □  0  0  Integer  2  Key  that  uniquely 

identifies  a  Subcategory 
for  describing  Site  Types 

3  SiteType  D  D  0  Text  50  Type  of  Site  (for  example, 

well,  discharge  pipe, 
regional  distribution  Site, 
potable  treatment  plant, 
single  user,  and  others) 

4  SiteTypeMemo  dl  dl  dl  Memo  —  Note  about  a  Site  Type 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 

Number  of  Fields: 
Number  of  Records 


tdsSiteT  ypeC  ategory 

List  of  Major  Categories  for  describing  Types  of  Sites 

2  Dependency:  Independent  Recursive:  □ 


Loading  Order:  1 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1  SiteTypeCategory_ID 

0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  major 

Category  for  describing 

Site  Types 

2  SiteTypeCategory 

□  n  0 

Text 

25 

Tenn  that  defines  a  major 
Category  of  Site  Types 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  SiteTypeSubcategory_ID  0  O  0  Integer  2 


2  SiteTypeCategory_ID  □  0  0  Integer  2 


3  SiteTypeSubcategory  D  O  0  Text  25 


Key  that  uniquely 
identifies  a  Subcategory 
for  describing  Site  Types 

Key  that  uniquely 
identifies  a  major 
Category  for  describing 
Site  Types 

Term  that  defines  a 
Subcategory  of  Site 
Types 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsState 

Table  Description: 

List  of  States  and  State  Codes 

Number  of  Fields: 

7 

Dependency: 

Independent 

Recursive:  □ 

Number  of  Records 

6 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd 

Type 

Size  Default 

Description 

1  StatelD 

0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  State  or 
Canadian  Province 

2  CountryAbbrv 

□  n  0 

Text 

3  "USA" 

Country  Abbreviation 
(USA  or  CAN) 

3  StateCode 

□  □  0 

Text 

2 

FIPS  State  Code,  or 
surrogate  for  Canadian 
Province 

4  StateAbbrv 

□  □  0 

Text 

2 

State  (or  Canadian 
Province)  Abbreviation 

5  StateName 

□  □  0 

Text 

50 

State  (or  Canadian 

Province)  Name 

6  StateLatitude 

□  □  □ 

Text 

30 

Latitude  coordinate 
(decimal  degrees  format) 
for  the  centroid  of  a  State 

7  StateLongitude 

□  □  □ 

Text 

30 

Longitude  coordinate 
(decimal  degrees  format) 
for  the  centroid  of  a  State 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  TimeInterval_ID  0  O  0  Integer  2  Key  that  uniquely 

identifies  a  Time  Interval 

2  Timelnterval  0  0  0  Text  25  Term  that  defines  a  Time 

Interval  (for  example, 
year,  month,  week,  day, 
and  others) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsUseGroup 

Table  Description: 

List  of  major  Groupings  for  New  Jersey  Water  Use  Types  that  classify  Sites 

Number  of  Fields: 

3 

Dependency: 

Independent 

Recursive:  □ 

Number  of  Records 

8 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  UseGroupID 

0  □  0  Integer 

2 

Key  that  uniquely 
identifies  a  Water  Use 

Group  classification  for  a 

Site 

2  UseGroupCode 

□  □  0  Text 

2 

Water  Use  Group  Code 

3  UseGroup 

□  □  0  Text 

50 

Water  Use  Group  Name 

or  short  description 


1-59 


Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

Table  Description: 

Number  of  Fields: 
Number  of  Records 


tdsUseType 

List  of  New  Jersey  Water  Use  Types  that  classify  Sites 

4  Dependency:  Partial  Recursive:  □ 

38  Loading  Order:  2 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  UseTypelD 


2  UseGroupID 


3  UseTypeCode 

4  UseType 


0  □  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Water  Use 
Type  classification  for  a 
Site 

□  00 

Integer 

2 

Key  that  uniquely 
identifies  a  Water  Use 
Group  classification  for  a 
Site 

□  □  0 

Text 

2 

Water  Use  Type  Code 
within  a  Use  Group 

□  □  0 

Text 

50 

Water  Use  Type  Code 
Name 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsVolumeUnitDecimal 


Table  Description:  List  of  choices  for  the  Decimal  part  of  a  VolumeUnit  (ten,  hundred, 
thousand,  and  others)  and  their  conversion  factor  to  Million  to  get  a 
common  Volume  unit  of  'million  gallons' 


Number  of  Fields:  3  Dependency:  Independent  Recursive:  0 

Number  of  Records  10  Loading  Order:  1 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  VolumeUnitDecimal_ID  0  0]  0  Integer 


2 


2  DecimalUnit 


□  □  0  Text  50 


3  ConversionToMillion 


D  D  0  Double 


8 


Key  that  uniquely 
identifies  a  Volume  Unit 
Decimal  component 

Term  used  to  describe  the 
Decimal  part  of  a  Volume 
Unit  (for  example, 
thousand,  million) 

Factor  used  to  convert 
Decimal  Unit  to  one 
equivalent  in  Millions 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdsVolumeUnitQuantity 


Table  Description:  List  of  choices  for  the  Quantity  part  of  a  VolumeUnit  (gallon,  cubic  feet, 
acre-feet,  and  others)  and  their  conversion  factor  to  Gallon  to  get  a 
common  Quantity  unit  of  'million  gallons' 


Number  of  Fields:  3  Dependency:  Independent  Recursive:  ED 

Number  of  Records  6  Loading  Order:  1 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  VolumeUnitQuantity_ID  0  EH  0  Integer 


2 


2  QuantityUnit 


□  □  0  Text  50 


3  ConversionToGallon 


D  D  0  Double 


8 


Key  that  uniquely 
identifies  a  Volume  Unit 
Quantity  component 

Term  used  to  describe  the 
Quantity  part  of  a  Volume 
Unit  (for  example,  gallons, 
cubic  feet,  acre-feet) 

Factor  used  to  convert 
Quantity  Unit  to  one 
equivalent  in  Gallons 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  WaterBodyType_ID  0  0  0  Integer  2  Key  that  uniquely 

identifies  a  Type  of 
Water  Body  represented 
by  a  water  Resource  (for 
example,  lake,  river, 
estuary) 


2  ResourceType_ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  water 
Resource  Type 

3  WaterBodyType 

□  □  0 

Text 

30 

Type  of  Water  Body 
describing  a  water 
Resource  (for  example, 
river,  lake,  estuary,  ocean, 
and  others) 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  WaterMgmntArea_ID  0  EH  0  Integer  2  Key  that  uniquely 

identifies  a  New  Jersey 
Water  Management  Area 

2  WaterRegion_ID  EH  0  0  Integer  2  Key  that  uniquely 

identifies  a  New  Jersey 
Water  Region 

3  WaterMgmntAreaCode  0  EH  0  Text  50  Two-digit  Code  used  to 

uniquely  identify  a  New 
Jersey  Water 
Management  Area 

4  WaterMgmntArea  D  D  0  Text  50  Name  of  New  Jersey 

Water  Management  Area 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdsWaterRegion 

Table  Description: 

List  of  New  Jersey  Water  Regions 

Number  of  Fields: 

3 

Dependency: 

Independent 

Recursive:  □ 

Number  of  Records 

6 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd  Type 

Size  Default 

Description 

1  WaterRegion  ID 

0  □  0  Integer 

2 

Key  that  uniquely 
identifies  a  New  Jersey 
Water  Region 

2  WaterRegionCode 

□  □  0  Text 

50 

Code  used  to  uniquely 
identify  a  New  Jersey 

Water  Region 

3  WaterRegion 

□  □  0  Text 

50 

Name  of  New  Jersey 

Water  Region 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdxAliasLabel 

Table  Description:  User-Extendable  List  of  standardized  Labels  used  for  Alias  assignments 

Number  of  Fields:  5  Dependency:  Partial  Recursive:  □ 

Number  of  Records  0  Loading  Order:  4 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1 

AliasLabel  ID 

0  □  0 

AutoNumber 

4 

Key  that  uniquely 

(Long) 

identifies  an  AliasLabel 

2 

DataSource  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Data  Source 

3 

AliasSource 

□  □  □ 

Text 

75 

Source  of  an  Alias; 
optional,  provides  more 
detail  within  a  DataSource 

4 

AliasLabel 

□  □  0 

Text 

50 

Label  for  an  Alias,  for 
example  StationID 

5 

AliasLabelMemo 

□  □  □ 

Memo 

— 

Note  about  an  Alias  Label 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  ConveyanceDetailLabel_ID  0  □  0  AutoNumber  4 

(Long) 


Key  that  uniquely 
identifies  a  Conveyance 
Detail  Label 


2  ConveyanceDetailLabel  O  EH  0  Text 


3  ConveyanceDetailLabelMemo  CH  dl  CH  Memo 


50  Label  describing  the 

numeric  or  textual  value 
of  a  Conveyance  Detail 

Note  about  a 
Conveyance  Detail  Label 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdxDataSource 

Table  Description:  User-Extendable  List  of  the  Sources  of  Data  being  stored 

Number  of  Fields:  4  Dependency:  Partial  Recursive:  □ 

Number  of  Records  4  Loading  Order:  3 


Field  Name 

PK  FK  Rqd 

Type 

Size 

Default  Description 

1 

DataSource  ID 

0 

□ 

0 

AutoNumber 

4 

Key  that  uniquely 

(Long) 

identifies  a  Data  Source 

2 

Owner  ID 

□ 

0 

0 

Long  Integer 

4 

Key  that  uniquely 
identifies  an  Owner 

3 

DataSource 

□ 

□ 

0 

Text 

75 

Data  Source  name 

4 

DataSourceMemo 

□ 

□ 

□ 

Memo 

_ 

Note  about  a  Data  Source 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdxLocationDetMethod 

Table  Description: 

User-Extendable  List  of  Location  Determination  Methods  for  Sites 

Number  of  Fields: 

2 

Dependency: 

Independent  Recursive:  □ 

Number  of  Records 

11 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd  Type 

Size  Default  Description 

LocationDetMethod  ID 

0 

□ 

0 

AutoNumber 

4 

Key  that  uniquely 

(Long) 

identifies  a  Location 
Determination  Method 

LocationDetMethod 

□ 

n 

0 

Text 

50 

Location  Determination 
Method 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdxPermitLabel 

Table  Description: 

User-Extendable  List  of  standardized  Labels  used  to  identify  different 

Permits 

Number  of  Fields: 

4 

Dependency:  Partial 

Recursive:  □ 

Number  of  Records 

3 

Loading  Order:  4 

Field  Name 

PK  FK  Rqd  Type  Size 

Default  Description 

PermitLabel  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Permit  Label 

DataSource  ID 

□  0  0 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Data  Source 

PermitLabel 

□  □  0 

Text 

50 

Label  identifying  a 
specific  type  of  Permit 
(for  example,  PWSID, 
BWA,  NJDPES) 

PermitLabelMemo 

□  □  □ 

Memo 

— 

Note  about  a  Permit  Label 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


ResourceDetailLabel  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Resource 
Detail  Label 

ResourceDetailLabel 

□  □  0 

Text 

50 

Label  describing  the 
numeric  or  textual  value 
of  a  Resource  Detail 

ResourceDetailLabelMemo 

□  □  □ 

Memo 

- 

Note  about  a  Resource 
Detail  Label 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  SiteDetailCategory  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Category  for 
describing  Details  about 
a  Site 

2  SiteDetailCategory 

□  □  0 

Text 

50 

Term  that  defines  a 
Category  for  describing 
Details  about  a  Site 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


1  SiteDetailLabel_ID  0  □  @  AutoNumber  4  Key  that  uniquely 

(Long)  identifies  a  Site  Detail 

Label 

2  SiteDetailCategory_ID  EH  0  0  Long  Integer  4  Key  that  uniquely 

identifies  a  Category  for 
describing  Details  about 
a  Site 

3  SiteDetailLabel  D  D  0  Text  50  Label  describing  the 

numeric  or  textual  value 
of  a  Site  Detail 

4  IsNumericDetail  EH  EH  0  Yes/No  1  Identifies  a  Site  Detail 

Label  for  numeric  values; 
'Yes'  only  for  labels 
associated  with  numeric 
values 

5  SiteDetailUnit  EH  EH  0  Text  50  Optional  Unit  for  a  Site 

Detail  Label,  but  Required 
for  labels  representing 
numeric  values 

6  SiteDetailLabelMemo  EH  EH  EH  Memo  —  Note  about  a  Site  Detail 

Label 
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Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name: 

tdxStaff 

Table  Description: 

User-Extendable  List  of  Staff  entering,  reviewing  or  evaluating  Transfer 
Volume  data 

Number  of  Fields: 

5 

Dependency: 

Independent 

Recursive:  □ 

Number  of  Records 

1 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd 

Type 

Size  Default 

Description 

1  StaffID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Staff  person 

2  Stafflnitials 

□  □  0 

Text 

4 

Initials  of  Staff  person 
(unique  code  for  each 
individual) 

3  StafFName 

□  □  0 

Text 

50 

Name  of  Staff  person 
(format:  last  name,  first 
name,  initial) 

4  StaffAffiliation 

□  □  0 

Text 

50 

Affiliation  of  Staff  person 

5  StaffMemo 

□  □  □ 

Memo 

— 

Note  about  Staff  person 

1-74 


Appendix  1:  Data  Dictionary  for  the  New  Jersey  Water-Transfer  Data  System  (NJWaTr) — Continued 


Table  Name:  tdxSystem 


Table  Description:  User-Extendable  List  of  Systems  consisting  of  two  or  more  associated  Sites 

Number  of  Fields:  5  Dependency:  Partial  Recursive:  0 

Number  of  Records  0  Loading  Order:  2 


Field  Name 


PK  FK  Rqd  Type  Size  Default  Description 


1  System_ID 

2  SystemType_ID 


3  SystemName 


4  ParentSystem_ID 


5  SystemMemo 


0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  System 

□  00 

Long  Integer 

4 

Key  that  uniquely 
identifies  a  Type  of 
System 

□  □  0 

Text 

200 

Name  of  a  System 
consisting  of  one  or  more 
Sites 

□  0  □ 

Long  Integer 

4 

Key  that  uniquely 
identifies  the  Parent 
System  of  the  current 
System  (accommodates 
nested  Systems) 

□  □  □ 

Memo 

— 

Note  about  a  System 
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Table  Name: 

tdxSystemType 

Table  Description: 

User-Extendable  List  of  Types  of  Systems  (aggregates  of  Sites) 

Number  of  Fields: 

3 

Dependency: 

Independent  Recursive:  □ 

Number  of  Records 

6 

Loading  Order: 

1 

Field  Name 

PK  FK  Rqd  Type 

Size  Default  Description 

1  SystemType_ID 

0  □  0 

AutoNumber 

4 

Key  that  uniquely 

(Long) 

identifies  a  Type  of 
System 

2  SystemType 

□  □  0 

Text 

40 

Type  classification  of  a 
System  consisting  of  one 
or  more  Sites 

3  SystemTypeMemo 

□  □  □  Memo 

- 

Note  about  a  System 

Type 
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VolumeDetailLabel  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Volume  Detail 
Label 

VolumeDetailLabel 

□  □  0 

Text 

50 

Label  describing  the 
numeric  or  textual  value 
of  a  Volume  Detail  (for 
example,  'Accuracy') 

VolumeDetailLabelMemo 

□  □  □ 

Memo 

— 

Note  about  a  Volume 

Detail  Label 
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Table  Name: 

tdxV  olumeMethod 

Table  Description: 

User-Extendable  List  of  Methods  used  to  measure  or  estimate  a  Transfer 

Volume 

Number  of  Fields: 

Number  of  Records 

4  Dependency: 

42  Loading  Order: 

Partial 

2 

Recursive:  O 

Field  Name 

PK  FK  Rqd  Type 

Size 

Default  Description 

1  VolumeMethod_ID  0  0  0  AutoNumber  4 

(Long) 


Key  that  uniquely 
identifies  a  Method  used 
to  determine  the  Volume 
of  a  Transfer 


2  VolumeMethodCategory_ID  D  0  0  Long  Integer  4 


Key  that  uniquely 
identifies  a  Category  of 
Volume  Determination 
Methods 


3  VolumeMethod 


□  □  0  Text 


4  VolumeMethodMemo 


□  □  □  Memo 


200  Name  or  short  description 

of  the  Method  used  for 
determining  the  Volume 
(quantity)  of  a  water 
Transfer 

Note  about  a  Volume 
Method 
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1  VolumeMethodCategory  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Category  of 
Volume  Determination 
Methods 

2  VolumeMethodCategory 

□  □  0 

Text 

50 

Term  that  defines  a 
Category  of  Volume 
Determination  Methods 
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Table  Name:  tdxVolumeUnit 

Table  Description:  User-Extendable  List  of  Units  and  common-unit  conversion  factors  used 
for  Transfer  Volumes 

Number  of  Fields:  7  Dependency:  Partial  Recursive:  EH 

Number  of  Records  10  Loading  Order:  2 

Field  Name 

PK  FK  Rqd 

Type 

Size 

Default 

Description 

1  VolumeUnit  ID 

0  □  0 

AutoNumber 

(Long) 

4 

Key  that  uniquely 
identifies  a  Volume  Unit 
(units  by  which  raw 

Volume  values  are 
originally  recorded  or 
estimated)  for  a  Transfer 

2  VolumeUnitDecimal  ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Volume  Unit 
Decimal  component 

3  VolumeUnitQuantity  ID 

□  0  0 

Integer 

2 

Key  that  uniquely 
identifies  a  Volume  Unit 
Quantity  component 

4  VolumeUnitAbbrv 

□  □  0 

Text 

50 

Abbreviation  commonly 
used  to  express  a  Volume 
Unit 

5  VolumeUnitPhrase 

□  □  0 

Text 

50 

-1 

Volume  Unit  Name  made 
of  Decimal,  Volume  and 
Time  component  terms 

6  MGConversion 

□  □  0 

Double 

8 

-1 

Conversion  value  to  be 
multiplied  against  a  Raw 
Volume  Value  recorded  in 
a  particular  Unit  to  create 
an  equivalent  value  for 
that  Volume  in  million 
gallons 

7  VolumeUnitMemo 

□  □  □ 

Memo 

— 

Note  about  a  Volume  Unit 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Site  Domains 

tdsSiteTypeCategory  (n  =  7) 


SiteTypeCategory_ID 

SiteTypeCategory 

0 

unknown 

1 

atmosphere 

2 

resource  interactor 

3 

transfer 

4 

treatment 

5 

unaccounted-for  water 

6 

user 

tdsSiteTypeSubcategory  (n  = 

13) 

SiteTypeSubcategory_ID 

SiteTypeC  ategory_ID 

SiteTypeSubcategory 

0 

0 

unknown 

1 

1 

atmosphere 

2 

2 

ground  water 

3 

2 

spring 

4 

2 

surface  water 

5 

3 

collection 

6 

3 

distribution 

7 

4 

postuse 

8 

4 

preuse 

9 

5 

unaccounted-for  water 

10 

6 

aggregate  user 

11 

6 

single  user 

12 

2 

ground  and  surface  water 

Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Site  Domains — Continued 


to 

I 

-£■ 


tdsSiteType  (n  =  36) 


SiteType_ID 

SiteTypeSubcategory_ID 

SiteType 

0 

0 

unknown 

1 

2 

ground-water  withdrawal 

2 

2 

wellfield 

3 

2 

withdrawal  well 

4 

2 

recharge  well 

5 

2 

ground-water  return  flow 

6 

3 

spring 

7 

4 

surface-water  withdrawal 

8 

4 

intake  pipe 

9 

4 

discharge  pipe 

10 

4 

surface-water  return  flow 

11 

6 

regional  distribution  system 

12 

6 

local  distribution  system 

13 

5 

regional  collection  system 

14 

5 

local  collection  system 

15 

6 

reclaimed  wastewater  system 

16 

6 

recycled  water  system 

17 

8 

potable-water  treatment  plant 

SiteTypeMemo 

Unknown  -  typically  used  as  a  place-holder  while  the  true  nature  of  a  Site  is  being  investigated 

Ground-water  withdrawal  from  a  general  area,  as  for  livestock  withdrawals  in  a  county 

A  series  of  wells  that  are  joined  together  by  a  manifold  metering  system  and  are  all  completed  in  the 
same  aquifer 

A  hole  in  the  ground  that  has  a  diameter  smaller  than  its  depth  from  which  water  is  withdrawn  for  use 

A  hole  in  the  ground  that  has  a  diameter  smaller  than  its  depth  through  which  water  is  pumped  back 
into  the  ground 

Ground-water  return  flow  to  a  general  area,  as  for  domestic  return  flow  in  a  county 

An  opening  in  the  earth  from  which  water  flows  without  pumping 

Surface-water  withdrawal  from  a  general  area,  as  for  livestock  withdrawals  in  a  county 

A  pipe  into  a  surface-water  body  through  which  water  is  removed  from  the  surface-water  body 

A  pipe  into  a  surface-water  body  through  which  water  is  returned  to  the  surface-water  body 

Surface-water  return  flow  to  a  general  area,  as  for  irrigation  return  flow  in  a  county 

A  pipe  or  system  of  pipes  conveying  water  to  another  regional  distribution  system  or  to  more  than 
one  local  distribution  system 

A  pipe  or  system  of  pipes  conveying  water  to  a  single  MCD  or  within  a  single  MCD 

A  pipe  or  system  of  pipes  conveying  wastewater  from  more  than  one  MCD  or  from  another  regional 
collection  system 

A  pipe  or  system  of  pipes  conveying  wastewater  from  a  single  MCD 
A  pipe  or  system  of  pipes  conveying  water  from  a  wastewater-treatment  plant  to  a  user 
A  pipe  or  system  of  pipes  conveying  water  from  one  user  to  another  user,  including  itself 
A  treatment  plant  that  prepares  water  to  meet  drinking-water  standards 
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Site  Domains — Continued 


tdsSiteType  (n 

=  36) — Continued 

SiteType_ID 

SiteTypeSubcategory_ID 

SiteType 

SiteTypeMemo 

18 

8 

industrial  treatment  plant 

A  treatment  plant  that  prepares  water  to  meet  standards  that  are  not  necessarily  drinking-water 
standards— may  be  higher  or  lower  standards 

19 

7 

wastewater-treatment  plant 

A  treatment  plant  that  prepares  wastewater  for  discharge  into  the  hydrologic  environment 

20 

11 

single  user 

A  user  for  which  individual  water  supply,  use,  consumptive  use,  or  return  flow  is  measured  or 
estimated 

21 

10 

Aggregate  County  user 

A  group  of  users,  defined  by  a  County  boundary,  for  which  supply,  use,  consumptive  use,  and  return 
flow  are  collectively  estimated 

22 

1 

Atmosphere  (consumptive  use) 

Atmosphere  (consumptive  use)  represents  water  that  is  evaporated  or  incorporated  into  products 

23 

9 

Unaccounted-for  water 

Unaccounted-for  water  represents  the  combination  of  leakage  from  distribution  systems  and  public 
use  of  water,  such  as  hydrant  flushing,  fire  fighting,  and  street  sweeping 

24 

10 

aggregate  MCD  user 

A  group  of  users,  defined  by  a  Minor  Civil  Division  boundary,  for  which  supply,  use,  consumptive 
use,  and  return  flow  are  collectively  estimated 

25 

10 

aggregate  HUC  user 

A  group  of  users,  defined  by  a  Hydrologic  Unit  boundary,  for  which  supply,  use,  consumptive  use, 
and  return  flow  are  collectively  estimated 

26 

10 

aggregate  State  user 

A  group  of  users,  defined  by  a  State  boundary,  for  which  supply,  use,  consumptive  use,  and  return 
flow  are  collectively  estimated 

27 

4 

Ranney  collector 

A  large  diameter  well  located  near  a  river 

28 

2 

Land  application 

Disposal  of  wastewater  over  a  field,  as  in  irrigation 

29 

2 

Recharge  basin 

Return  of  freshwater  or  wastewater  into  a  specially  designed  basin 

30 

12 

Inflow  and  Infiltration  water 

Inflow  and  infiltration  water  represents  the  combination  of  inflow  from  surface  water  and  infiltration 
from  ground  water  into  a  wastewater-collection  system 

31 

6 

Drinking  Water  Service  Area 

Area  that  is  served  by  one  set  of  distribution  pipes  and  regulated  under  one  BSDW  PWS  ID  number 

32 

11 

BWA  Use  area 

A  place-of-use  defined  by  a  BWA  withdrawal 

33 

6 

DW  use  area 

A  group  of  users,  defined  by  a  DW  Service  Area  boundary,  for  which  supply,  use,  consumptive  use, 
and  return  flow  are  collectively  determined 

34 

2 

Intake  pipe  (ground  water) 

A  pipe  into  a  ground-water-fed  pond  through  which  water  is  removed  from  the  water  body 

35 

2 

Discharge  pipe  (ground  water) 

A  pipe  into  a  ground-water-fed  pond  through  which  water  is  returned  to  the  water  body 
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Site  Domains — Continued 


tdsUseGroup  (n  =  8  for  New  Jersey) 


UseGroup_ID 

UseGroupCode 

UseGroup 

0 

- 

undefined 

1 

1 

power  generation 

2 

2 

mining 

3 

3 

industrial 

4 

4 

commercial 

5 

5 

potable  supply 

6 

6 

irrigation 

7 

7 

agricultural 

tdsUseType  (n  =  38  for  New  Jersey) 


UseType_ID 

UseGroup_ID 

UseTypeCode 

UseType 

0 

0 

- 

not  classified 

1 

1 

E 

power  generation 

2 

1 

L 

geothermal/heat  pump 

3 

2 

K 

mining 

4 

3 

A 

air  conditioning 

5 

3 

D 

dewatering 

6 

3 

J 

cooling  (industrial) 

7 

3 

N 

industrial 

8 

3 

W 

injection 

9 

3 

X 

pollution  control 

10 

4 

c 

commercial  (non-com) 

11 

4 

F 

fire 

12 

4 

R 

recreation  (non-comm) 

13 

5 

B 

bottling 

14 

5 

H 

domestic 

15 

5 

M 

medicinal  value 

16 

5 

0 

public  non-community 

17 

5 

P 

public  supply 
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Site  Domains — Continued 


tdsUseType  (n  = 

38  for  New  Jersey) — Continued 

UseType_ID 

UseGroup_ID 

UseTypeCode 

UseType 

18 

5 

T 

institutional 

19 

5 

U 

unused 

20 

5 

Y 

desalination 

21 

5 

Z 

other 

22 

6 

G 

golf 

23 

6 

I 

non-ag  irrigation 

24 

7 

Q 

aquaculture 

25 

7 

S 

general  agriculture 

26 

1 

EH 

hydro  power  generation 

27 

1 

ET 

thermal  power  generation 

28 

7 

SB 

blueberries 

29 

7 

SC 

cranberries 

30 

7 

SF 

field  crops 

31 

7 

SG 

greenhouse 

32 

7 

SI 

agriculture  irrigation 

33 

7 

SS 

sod 

34 

7 

ST 

tree  fruit 

35 

7 

SV 

vegetables,  leaf  crops 

36 

7 

SX 

Christmas  trees 

37 

5 

NF 

industrial  -  food  processing 

tdxSiteDetailCategory  (currently  n 

=  5) 

SiteDetailCategory_ID 

SiteDetailCategory 

1 

Count 

2 

Status 

3 

Description 

4 

Coefficient  count 

5 

Percent 

Appendix  2.  NJWaTr  Domain  Table 

Site  Domains — Continued 


to 

I 

00 


tdxSiteDetailLabel  (example) 
[SiteDetailLabelMemo  field  not  shown] 


SiteDetailLabel_ID  SiteDetailCategory_ID 
1  1 

2  1 

3  1 

4  1 

5  2 

6  3 

7  3 

8  3 

9  3 

10  3 

11  3 

12  3 

13  4 

14  1 

15  1 


Subject  Area — Continued 


SiteDetailLabel 

IsNumericDetail 

SiteDetailUnit 

Population  served 

Yes 

People 

Number  of  employees 

Yes 

People 

Livestock 

Yes 

Animals 

Acres  irrigated-sprinkler 

Yes 

Acres 

Activity  status 

no 

X 

Design  capacity 

Yes 

Mgal/d 

Storage  capacitys 

Yes 

Mgal 

Service  connections 

Yes 

Count 

Well  depth 

Yes 

Feet 

Diameter 

Yes 

Inches 

Pumping  rate 

Yes 

Gal/minute 

Pipe  length 

Yes 

Feet 

Aggregate  (sand,  gravel) 

Yes 

Tons 

Energy 

Yes 

Kwh 

Head 

Yes 

Feet 
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Site  Domains — Continued 


tdxSystemType  (currently  n  =  6) 

SysteniTypelD  SystemType  SystemTypeMemo 

1  Public  Supplier 

2  Public  Wastewater  system 

3  Energy  Producer 

4  User 

5  Town 

6  County 


tdxSystem  (example) 


System_ID 

SystemType_ID 

SystemName 

ParentSystem_ID  SystemMemo 

1 

4 

My  Industry,  Inc. 

2 

1 

Suburban  Water  Co. 
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Conveyance  Domains 


tdsConveyanceType  (n  =  7) 


ConveyanceType_ID 

ConveyanceType 

ConveyanceTypeMemo 

1 

Pipe 

Long  tube  or  hollow  body  for  conducting  water;  closed  to  atmosphere  and  earth 

2 

Canal 

Artificial  waterway  for  draining  or  irrigating  land  or  for  connecting  2  rivers,  includes  ditches;  open  to 
atmosphere  and  earth 

3 

Aqueduct 

Large  conduit  for  carrying  water;  closed  to  atmosphere,  closed  to  earth 

4 

Conduit 

Artificial  waterway  for  conveying  water  that  is  open  to  atmosphere  and  closed  to  earth 

5 

Mixed 

Connection  between  2  sites  that  combines  2  or  more  conveyance  types— varies  from  being  open  or  closed 
throughout  its  extent 

6 

Virtual 

Connection  between  2  Sites 

7 

Truck 

Two  sites  connected  by  truck  (water  delivered  by  truck) 

tdxConveyanceDetailLabel  (currently  n  =  5) 


ConveyanceDetailLabel_ID 

ConveyanceDetailLabel 

ConveyanceDetailLabelMemo 

1 

Pipe  size  -  inches 

2 

Panal  system  length  -  miles 

3 

Aqueduct  system  length  -  miles 

4 

Conduit  system  length  -  miles 

5 

Mixed  system  length  -  miles 
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Conveyance  Domains — Continued 


tdsConveyanceActionCategory  (n  =  27) 


ConveyanceActionCategory_ID 

ConveyanceActionCategory 

0 

Unknown 

1 

collection  collection 

2 

collection  treatment 

3 

consumptive  use 

4 

conveyance  loss 

5 

distribution  distribution 

6 

distribution  user 

7 

distribution  treatment 

8 

infiltration 

9 

inflow 

10 

leakage 

11 

reclaimed  wastewater 

12 

recycled  water 

13 

resource  transfer 

14 

treatment  collection 

15 

treatment  distribution 

16 

treatment  resource 

17 

treatment  user 

18 

user  collection 

19 

user  return 

20 

user  treatment 

21 

withdrawal  distribution 

22 

withdrawal  treatment 

23 

withdrawal  user 

24 

unaccounted  for  use 

25 

inflow  and  infiltration 

26 

collection  return 
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Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) 


C  on  vey  anc  e  Ac  t  i  o  n_ID 

Convey  ance  ActionC  ategory_lD 

1  ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

0 

0 

From  unknown  To  unknown 

0 

0 

1 

13 

From  ground-water  withdrawal  To  recharge  well 

1 

4 

2 

13 

From  ground-water  withdrawal  To  discharge  pipe 

1 

9 

3 

13 

From  wellfield  To  recharge  well 

2 

4 

4 

13 

From  wellfield  To  discharge  pipe 

2 

9 

5 

13 

From  withdrawal  well  To  recharge  well 

3 

4 

6 

13 

From  withdrawal  well  To  discharge  pipe 

3 

9 

7 

13 

From  spring  To  recharge  well 

6 

4 

8 

13 

From  spring  To  discharge  pipe 

6 

9 

9 

13 

From  surface-water  withdrawal  To  recharge  well 

7 

4 

10 

13 

From  surface-water  withdrawal  To  discharge  pipe 

7 

9 

11 

13 

From  intake  pipe  To  recharge  well 

8 

4 

12 

13 

From  intake  pipe  To  discharge  pipe 

8 

9 

13 

22 

Front  ground-water  withdrawal  To  potable-water  treatment  plant 

1 

17 

14 

22 

From  wellfield  To  potable-water  treatment  plant 

2 

17 

15 

22 

From  withdrawal  well  To  potable-water  treatment  plant 

3 

17 

16 

22 

Front  spring  To  potable-water  treatment  plant 

6 

17 

17 

22 

Front  surface-water  withdrawal  To  potable-water  treatment  plant 

7 

17 

18 

22 

Front  intake  pipe  To  potable-water  treatment  plant 

8 

17 

19 

22 

Front  ground-water  withdrawal  To  industrial  treatment  plant 

1 

18 

20 

22 

Front  wellfield  To  industrial  treatment  plant 

2 

18 

21 

22 

Front  withdrawal  well  To  industrial  treatment  plant 

3 

18 

22 

22 

Front  spring  To  industrial  treatment  plant 

6 

18 

23 

22 

Front  surface-water  withdrawal  To  industrial  treatment  plant 

7 

18 

24 

22 

Front  intake  pipe  To  industrial  treatment  plant 

8 

18 

25 

21 

Front  ground-water  withdrawal  To  regional  distribution  system 

1 

11 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

26 

21 

From  wellfield  To  regional  distribution  system 

2 

11 

27 

21 

From  withdrawal  well  To  regional  distribution  system 

3 

11 

28 

21 

From  spring  To  regional  distribution  system 

6 

11 

29 

21 

From  surface-water  withdrawal  To  regional  distribution  system 

7 

11 

30 

21 

From  intake  pipe  To  regional  distribution  system 

8 

11 

31 

21 

From  ground-water  withdrawal  To  local  distribution  system 

1 

12 

32 

21 

From  wellfield  To  local  distribution  system 

2 

12 

33 

21 

From  withdrawal  well  To  local  distribution  system 

3 

12 

34 

21 

From  spring  To  local  distribution  system 

6 

12 

35 

21 

From  surface-water  withdrawal  To  local  distribution  system 

7 

12 

36 

21 

From  intake  pipe  To  local  distribution  system 

8 

12 

37 

23 

From  ground-water  withdrawal  To  single  user 

1 

20 

38 

23 

From  wellfield  To  single  user 

2 

20 

39 

23 

From  withdrawal  well  To  single  user 

3 

20 

40 

23 

From  spring  To  single  user 

6 

20 

41 

23 

From  surface-water  withdrawal  To  single  user 

7 

20 

42 

23 

From  intake  pipe  To  single  user 

8 

20 

43 

23 

From  ground-water  withdrawal  To  aggregate  County  user 

1 

21 

44 

23 

From  wellfield  To  aggregate  County  user 

2 

21 

45 

23 

From  withdrawal  well  To  aggregate  County  user 

3 

21 

46 

23 

From  spring  To  aggregate  County  user 

6 

21 

47 

23 

From  surface-water  withdrawal  To  aggregate  County  user 

7 

21 

48 

23 

From  intake  pipe  To  aggregate  County  user 

8 

21 

49 

15 

From  potable-water  treatment  plant  To  regional  distribution  system 

17 

11 

50 

15 

From  potable-water  treatment  plant  To  local  distribution  system 

17 

12 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

51 

14 

From  potable-water  treatment  plant  To  local  collection  system 

17 

14 

52 

5 

From  regional  distribution  system  To  regional  distribution  system 

11 

11 

53 

5 

From  regional  distribution  system  To  local  distribution  system 

11 

12 

54 

6 

From  local  distribution  system  To  single  user 

12 

20 

55 

7 

From  local  distribution  system  To  industrial  treatment  plant 

12 

18 

56 

17 

From  industrial  treatment  plant  To  single  user 

18 

20 

57 

6 

From  local  distribution  system  To  aggregate  County  user 

12 

21 

58 

18 

From  single  user  To  local  collection  system 

20 

14 

59 

18 

From  aggregate  County  user  To  local  collection  system 

21 

14 

60 

19 

From  single  user  To  recharge  well 

20 

4 

61 

19 

From  single  user  To  ground-water  return  flow 

20 

5 

62 

19 

From  single  user  To  discharge  pipe 

20 

9 

63 

19 

From  single  user  To  surface-water  return  flow 

20 

10 

64 

19 

From  aggregate  County  user  To  recharge  well 

21 

4 

65 

19 

From  aggregate  County  user  To  ground-water  return  flow 

21 

5 

66 

19 

From  aggregate  County  user  To  discharge  pipe 

21 

9 

67 

19 

From  aggregate  County  user  To  surface-water  return  flow 

21 

10 

68 

1 

From  local  collection  system  To  regional  collection  system 

14 

13 

69 

1 

From  regional  collection  system  To  regional  collection  system 

13 

13 

70 

2 

From  local  collection  system  To  wastewater-treatment  plant 

14 

19 

71 

2 

From  regional  collection  system  To  wastewater-treatment  plant 

13 

19 

72 

20 

From  single  user  To  wastewater-treatment  plant 

20 

19 

73 

14 

From  industrial  treatment  plant  To  local  collection  system 

18 

14 

74 

11 

From  wastewater-treatment  plant  To  reclaimed  wastewater  system 

19 

15 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

75 

11 

From  reclaimed  wastewater  system  To  single  user 

15 

20 

76 

11 

From  reclaimed  wastewater  system  To  aggregate  County  user 

15 

21 

77 

12 

From  single  user  To  recycled  water  system 

20 

16 

78 

12 

From  recycled  water  system  To  single  user 

16 

20 

79 

16 

From  industrial  treatment  plant  To  recharge  well 

18 

4 

80 

16 

From  industrial  treatment  plant  To  ground-water  return  flow 

18 

5 

81 

16 

From  industrial  treatment  plant  To  discharge  pipe 

18 

9 

82 

16 

From  industrial  treatment  plant  To  surface-water  return  flow 

18 

10 

83 

16 

From  wastewater-treatment  plant  To  recharge  well 

19 

4 

84 

16 

From  wastewater-treatment  plant  To  ground-water  return  flow 

19 

5 

85 

16 

From  wastewater-treatment  plant  To  discharge  pipe 

19 

9 

86 

16 

From  wastewater-treatment  plant  To  surface-water  return  flow 

19 

10 

87 

8 

From  ground-water  withdrawal  To  local  collection  system 

1 

14 

88 

8 

From  ground-water  withdrawal  To  regional  collection  system 

1 

13 

89 

9 

From  surface-water  withdrawal  To  local  collection  system 

7 

14 

90 

9 

From  surface-water  withdrawal  To  regional  collection  system 

7 

13 

91 

10 

From  local  distribution  system  To  ground-water  return  flow 

12 

5 

92 

10 

From  regional  distribution  system  To  ground-water  return  flow 

11 

5 

93 

10 

From  local  collection  system  To  ground-water  return  flow 

14 

5 

94 

10 

From  regional  collection  system  To  ground-water  return  flow 

13 

5 

95 

3 

From  single  user  To  Atmosphere  (consumptive  use) 

20 

22 

96 

3 

From  aggregate  County  user  To  Atmosphere  (consumptive  use) 

21 

22 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

97 

4 

From  ground-water  withdrawal  To  ground-water  return  flow 

1 

5 

98 

4 

From  surface-water  withdrawal  To  ground-water  return  flow 

7 

5 

99 

19 

From  aggregate  MCD  user  To  recharge  well 

24 

4 

too 

19 

From  aggregate  MCD  user  To  ground-water  return  flow 

24 

5 

101 

19 

From  aggregate  MCD  user  To  discharge  pipe 

24 

9 

102 

19 

From  aggregate  MCD  user  To  surface-water  return  flow 

24 

10 

103 

18 

From  aggregate  MCD  user  To  local  collection  system 

24 

14 

104 

3 

From  aggregate  MCD  user  To  Atmosphere  (consumptive  use) 

24 

22 

105 

19 

From  aggregate  HUC  user  To  recharge  well 

25 

4 

106 

19 

From  aggregate  HUC  user  To  ground-water  return  flow 

25 

5 

107 

19 

From  aggregate  HUC  user  To  discharge  pipe 

25 

9 

108 

19 

From  aggregate  HUC  user  To  surface-water  return  flow 

25 

10 

109 

18 

From  aggregate  HUC  user  To  local  collection  system 

25 

14 

110 

3 

From  aggregate  HUC  user  To  Atmosphere  (consumptive  use) 

25 

22 

111 

19 

From  aggregate  State  user  To  recharge  well 

26 

4 

112 

19 

From  aggregate  State  user  To  ground-water  return  flow 

26 

5 

113 

19 

From  aggregate  State  user  To  discharge  pipe 

26 

9 

114 

19 

From  aggregate  State  user  To  surface-water  return  flow 

26 

10 

115 

18 

From  aggregate  State  user  To  local  collection  system 

26 

14 

116 

3 

From  aggregate  State  user  To  Atmosphere  (consumptive  use) 

26 

22 

117 

13 

From  Ranney  collector  To  recharge  well 

27 

4 

118 

13 

From  Ranney  collector  To  discharge  pipe 

27 

9 

119 

21 

From  Ranney  collector  To  regional  distribution  system 

27 

11 

120 

21 

From  Ranney  collector  To  local  distribution  system 

27 

12 

121 

22 

From  Ranney  collector  To  potable-water  treatment  plant 

27 

17 

122 

22 

From  Ranney  collector  To  industrial  treatment  plant 

27 

18 

LVZ 


Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

123 

23 

From  Ranney  collector  To  single  user 

27 

20 

124 

23 

From  Ranney  collector  To  aggregate  County  user 

27 

21 

125 

23 

From  ground-water  withdrawal  To  aggregate  MCD  user 

1 

24 

126 

23 

From  wellfield  To  aggregate  MCD  user 

2 

24 

127 

23 

From  withdrawal  well  To  aggregate  MCD  user 

3 

24 

128 

23 

From  spring  To  aggregate  MCD  user 

6 

24 

129 

23 

From  surface-water  withdrawal  To  aggregate  MCD  user 

7 

24 

130 

23 

From  intake  pipe  To  aggregate  MCD  user 

8 

24 

131 

6 

From  local  distribution  system  To  aggregate  MCD  user 

12 

24 

132 

11 

From  reclaimed  wastewater  system  To  aggregate  MCD  user 

15 

24 

133 

23 

From  ground-water  withdrawal  To  aggregate  HUC  user 

1 

25 

134 

23 

From  wellfield  To  aggregate  HUC  user 

2 

25 

135 

23 

From  withdrawal  well  To  aggregate  HUC  user 

3 

25 

136 

23 

From  spring  To  aggregate  HUC  user 

6 

25 

137 

23 

From  surface-water  withdrawal  To  aggregate  HUC  user 

7 

25 

138 

23 

From  intake  pipe  To  aggregate  HUC  user 

8 

25 

139 

6 

From  local  distribution  system  To  aggregate  HUC  user 

12 

25 

140 

11 

From  reclaimed  wastewater  system  To  aggregate  HUC  user 

15 

25 

141 

23 

From  ground-water  withdrawal  To  aggregate  State  user 

1 

26 

142 

23 

From  wellfield  To  aggregate  State  user 

2 

26 

143 

23 

From  withdrawal  well  To  aggregate  State  user 

3 

26 

144 

23 

From  spring  To  aggregate  State  user 

6 

26 

145 

23 

From  surface-water  withdrawal  To  aggregate  State  user 

7 

26 

146 

23 

From  intake  pipe  To  aggregate  State  user 

8 

26 

147 

6 

From  local  distribution  system  To  aggregate  State  user 

12 

26 

148 

11 

From  reclaimed  wastewater  system  To  aggregate  State  user 

15 

26 

149 

24 

From  regional  distribution  system  To  Unaccounted-for  water 

11 

23 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

150 

24 

From  local  distribution  system  To  Unaccounted-for  water 

12 

23 

151 

25 

From  Inflow  and  Infiltration  water  To  regional  collection  system 

30 

13 

152 

25 

From  Inflow  and  Infiltration  water  To  local  collection  system 

30 

14 

153 

11 

From  industrial  treatment  plant  To  Land  application 

18 

28 

154 

11 

From  wastewater-treatment  plant  To  Land  application 

19 

28 

155 

11 

From  single  user  To  Land  application 

20 

28 

156 

11 

From  aggregate  County  user  To  Land  application 

21 

28 

157 

11 

From  aggregate  MCD  user  To  Land  application 

24 

28 

158 

11 

From  aggregate  HUC  user  To  Land  application 

25 

28 

159 

11 

From  aggregate  State  user  To  Land  application 

26 

28 

160 

13 

From  ground-water  withdrawal  To  Recharge  basin 

1 

29 

161 

13 

From  wellfield  To  Recharge  basin 

2 

29 

162 

13 

From  withdrawal  well  To  Recharge  basin 

3 

29 

163 

13 

From  spring  To  Recharge  basin 

6 

29 

164 

13 

From  surface-water  withdrawal  To  Recharge  basin 

7 

29 

165 

13 

From  intake  pipe  To  Recharge  basin 

8 

29 

166 

13 

From  industrial  treatment  plant  To  Recharge  basin 

18 

29 

167 

16 

From  wastewater-treatment  plant  To  Recharge  basin 

19 

29 

168 

16 

From  single  user  To  Recharge  basin 

20 

29 

169 

19 

From  aggregate  County  user  To  Recharge  basin 

21 

29 

170 

19 

From  aggregate  MCD  user  To  Recharge  basin 

24 

29 

171 

19 

From  aggregate  HUC  user  To  Recharge  basin 

25 

29 

172 

19 

From  aggregate  State  user  To  Recharge  basin 

26 

29 

173 

23 

From  withdrawal  well  To  Drinking  Water  Service  Area 

3 

31 

174 

23 

From  withdrawal  well  To  BWA  use  area 

3 

32 

175 

23 

From  spring  To  BWA  use  area 

6 

32 

176 

23 

From  intake  pipe  To  Drinking  Water  Service  Area 

8 

31 

2-19 


Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Conveyance  Domains — Continued 


tdsConveyanceAction  (n  =  190) — Continued 


ConveyanceAction_ID 

Con  vey  ance  ActionC  ategory_ID 

ConveyanceActionPhrase 

SiteTypeFromID 

SiteTypeToID 

177 

23 

From  intake  pipe  To  BWA  use  area 

8 

32 

178 

23 

From  unknown  To  Drinking  Water  Service  Area 

0 

31 

179 

23 

From  unknown  To  BWA  use  area 

0 

32 

180 

23 

From  ground-water  withdrawal  To  unknown 

1 

0 

181 

3 

From  BWA  use  area  To  Atmosphere  (consumptive  use) 

32 

22 

182 

5 

From  Drinking  Water  Service  Area  To  Drinking  Water  Service  Area 

31 

31 

183 

6 

From  Drinking  Water  Service  Area  To  DW  Use  Area 

31 

33 

184 

24 

From  Drinking  Water  Service  Area  To  Unaccounted-for  water 

31 

23 

185 

3 

From  DW  Use  Area  To  Atmosphere  (consumptive  use) 

33 

22 

186 

26 

From  regional  collection  system  To  discharge  pipe 

13 

9 

187 

21 

From  spring  To  Drinking  Water  Service  Area 

6 

31 

188 

18 

From  DW  Use  Area  To  regional  distribution  system 

33 

11 

189 

25 

From  Inflow  and  Infiltration  water  To  regional  distribution  system 

30 

11 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Transfer/Volume  Domains 


tdsVolumeUnitDecimal  (n  =  10) 


VolumeUnitDecimal_ID 

DecimalUnit 

ConversionToMillion 

0 

one 

0.000001 

1 

ten 

0.00001 

2 

hundred 

0.0001 

3 

thousand 

0.001 

4 

ten  thousand 

0.01 

5 

hundred  thousand 

0.1 

6 

million 

1 

7 

ten  million 

10 

8 

hundred  million 

too 

9 

billion 

1000 

tdsVolumeUnitQuantity  (n  =  6) 

VolumeUnitQuantity_ID 

QuantityUnit 

ConversionToGallon 

1 

gallons 

1 

2 

cubic  feet 

7.48 

3 

acre-feet 

325851 

4 

acre-inch 

27154 

5 

cubic  inch 

0.00433 

6 

liter 

0.2642 

Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Transfer/Volume  Domains — Continued 


tdxVolumeUnit  (currently  n  =  10) 
[VolumeUnitMemo  field  not  shown] 


VolumeUnit_ID 

VolumeUnitDecimal_ID 

VolumeUnitQuantity_ID 

VolumeUnitAbbrv 

VolumeUnitPhrase 

MGConversion 

1 

6 

1 

Mgal 

million  gallons 

1 

2 

0 

2 

eft 

cubic  feet 

0.00000748 

3 

3 

2 

Tcf 

thousand  cubic  feet 

0.00748 

4 

0 

3 

acre-feet 

acre-feet 

0.325851 

5 

3 

3 

Tacre-feet 

thousand  acre-feet 

325.851 

6 

0 

1 

gal 

gallons 

0.000001 

7 

3 

1 

Tgal 

thousand  gallons 

0.001 

8 

0 

4 

acre-inch 

acre-inch 

0.027154 

9 

0 

5 

cinch 

cubic  inch 

0.00000000433 

10 

9 

1 

Bgal 

billion  gallons 

1000 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Transfer/Volume  Domains — Continued 

tdxStaff  (example) 


StaffJD 

Stafflnitials 

StaffName 

StaffAffiliation 

StaffMemo 

1 

NJGS 

NJGS 

NJGS 

Generic  entry  for  NJGS  staff 

tdxVolumeDetailLabel  (example) 


VolumeDetailLabel_ID 

VolumeDetailLabel 

VolumeDetailLabelMemo 

1 

Accuracy 

tdxVolumeMethodCategory  (currently  n  =  12) 


VolumeMethodCategory_ID 

VolumeMethodCategory 

0 

Unknown  Method 

1 

Metered 

2 

Field  estimate 

3 

Coefficient  estimate 

4 

Reported 

5 

Intuition 

6 

Percent  of  metered 

7 

Percent  of  derived  value 

8 

Difference  between  metered  values 

9 

Difference  between  derived  values 

10 

Permit 

11 

Volumetric 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Transfer/Volume  Domains — Continued 


tdxVolumeMethod  (currently  n  =  42) 
[VolumeMethodMemo  field  not  shown] 


VolumeMethod_ID  VolumeMethodCategory_ID 


0  0 

1  0 

2  1 

3  1 

4  1 

5  1 

6  1 

7  2 

8  2 

9  3 

10  3 

11  3 

12  3 

13  3 

14  3 

15  3 

16  3 

17  3 

18  1 

19  7 


20 

21 

22 

23 

24 

25 

26 


6 

10 

6 

6 

7 

7 

2 


VolumeMethod 

Unknown  method 
Unknown  source,  unknown  method 
Uncalibrated  cumulative  meter 
Calibrated  instantaneous  meter  with  time  meter 
Calibrated  instantaneous  meter  with  time  estimate 
Uncalibrated  instantaneous  meter  with  time  meter 
Uncalibrated  instantaneous  meter  with  time  estimate 
Estimated  pumping  rate  with  time  meter 
Estimated  pumping  rate  with  time  estimate 
IWR-MAIN  coefficient  with  Dun-Bradstreet  values 
IWR-MAIN  coefficient  with  Census  Bureau  values 
Local  coefficient  with  Dun-Bradstreet  values 
Local  coefficient  with  Census  Bureau  values 
Power  coefficient  with  power-consumption  data 
Agriculture  coefficient  with  landsat  data 
Livestock  coefficient  with  Agriculture  Census  data 
Agriculture  coefficient  with  Agriculture  Census  data 
NWUIP  coefficient  with  Census  data 
Calibrated  cumulative  meter 

IWR-MAIN  coefficient  applied  to  Dun-Bradstreet  values  to  determine  water  use  and  use  Census  Bureau 
data  to  proportion  public  supply/disposal  from  self  supply/disposal 

Metered  withdrawal  data  multiplied  by  consumptive-use  percentage 
Permitted  volume 

Metered  withdrawal  data  multiplied  by  local  distribution  system  percentage 
Metered  delivery  data  multiplied  by  consumptive-use  percentage 
Aggregated  data  multiplied  by  land-  and  employee-based  percentage 
Water-use  value  multiplied  by  consumptive-use  percentage 
Stream  gage-USGS 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Transfer/Volume  Domains — Continued 


tdxVolumeMethod  (currently  n  =  42) — Continued 

VolumeMethod_ID  Vo  1  u  m  e  M  e  t  h  o  d  C  at  e  g  o  ry_ID  VolumeMethod 


27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 


2  Stream  gage-other  than  USGS 

11  Known  volume,  such  as  truck  times  the  number  of  trucks  over  a  specified  time  periode 

7  Public  supply  withdrawals  multiplied  by  unaccounted-for  use  percentage 

8  Difference  between  metered  withdrawals  and  billed  consumption 

6  Metered  wastewater  values  multiplied  by  population-based  percentage 

7  Percent  Total  aggregate  water  use  multiplied  by  percent  of  wells  in  different  aquifers  for  MCD  from  VTDEC,  WSD  well 
inventory  database 

7  Difference  between  Census  population  and  population  on  public  supply. 

9  Difference  between  registered  withdrawals  and  public-supply  deliveries,  factoring  in  all  connected  MCDs 

7  Volume  method  #20  times  percentage:  95%  bedrock  and  5%glacial  deposits  aquifer 

9  Average  irrigation  needs  less  actual  precipitation;  gw/sw  split  by  guestimate 

3  Livestock  coefficient  with  Agriculture  Census  data  plus  count  of  dairy  cows  (from  VTDOA)  times  water-use  coefficient 

1  Metered  data;  unknown  type 

9  Trying  to  correct  an  error,  placehold  volume  method 

3  SDWIS  population  times  70  gal/person/day,  divided  among  wells  as  appropriate,  85%  return  flow 

2  Estimated  based  on  reported  other  months 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Location  Domains 


tdsLocation  Scale  (n=8) 


LocationScalelD 

LocationScale 

0 

Unknown  Scale 

1 

Point 

2 

MCD/Town 

3 

County 

4 

State 

5 

HUCAVatershed 

6 

Irregular  Area 

7 

Undefined  Area 

tdxLocationDetMethod  (currently  n=ll) 

LocationDetMethod_ID 

LocationDetMelhod 

0 

Unknown  Method 

1 

Centroid  of  MCD 

2 

Centroid  of  County 

3 

Centroid  of  HUCAVatershed 

4 

GPS  field 

5 

Topographic  map 

6 

Surveyed  in 

7 

Atlas  software 

8 

Dun  &  Bradstreet  Info  Service 

9 

EPA-SDWIS  database 

10 

Geographic  Information  Svstem 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Location  Domains — Continued 


tdsState  (n  =  6  for  New  Jersey  and  surrounding  states) 

[Not  shown  arc  the  fields  StateLatitude  and  StateLongitude] 


State_ID 

Country  Abbrv 

StateCode 

StateAbbrv 

StateName 

0 

USA 

00 

XX 

No  State  Identified 

1 

USA 

34 

NJ 

New  Jersey 

2 

USA 

10 

DE 

Delaware 

3 

USA 

24 

MD 

Maryland 

4 

USA 

36 

NY 

New  York 

5 

USA 

42 

PA 

Pennsylvania 

tdsCounty  (sample  from  n  =  178  for  New  Jersey  and  surrounding  states) 
[Not  shown  arc  the  fields  CountyLatitude  and  CountyLongitude] 


County  _ID 

State_ID 

StateCountyCode 

CountyCode 

28 

1 

34001 

001 

29 

1 

34003 

003 

30 

1 

34005 

005 

31 

1 

34007 

007 

32 

1 

34009 

009 

33 

1 

34011 

011 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Location  Domains — Continued 


tdsMCD  (sample  from  n  =  4,479  for  New  Jersey  and  surrounding  states) 
[Not  shown  arc  the  fields  MCDLatitude  and  MCDLongitude] 


MCD_ID 

County  _ID 

DroughtRegion_ID 

StateMCDCode 

MCDCode 

MCDType 

MCDName 

MCDShortName 

322 

28 

6 

3400100 

00100 

City 

Absecon  city 

Absecon 

323 

28 

6 

3402080 

02080 

City 

Atlantic  City  city 

Atlantic  City 

324 

28 

6 

3407810 

07810 

City 

Brigantine  city 

Brigantine 

325 

28 

6 

3408680 

08680 

Borough 

Buena  borough 

Buena 

tdsDroughtRegion  (n  =  7) 

DroughtRegion_ID 

DroughtRegionCode 

DroughtRegion 

0 

n/a 

Not  Applicable 

1 

NE 

Northeast 

2 

NW 

Northwest 

3 

C 

Central 

4 

sw 

Southwest 

5 

CN 

Coastal,  North 

6 

cs 

Coastal,  South 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Location  Domains — Continued 


tdsHUC  (sample  from  n  =  935  for  New  Jersey  and  surrounding  states) 
[Not  shown  arc  the  fields  HUCllName,  HUC8,  and  HUC8Name] 


HUC_ID 

WaterMgmntArea_ID 

WatershedCode 

HUC14 

HUC14Name 

HUC11 

2 

0 

02BA01 

02020007010010 

Wallkill  R/Lake  Mohawk  (above  Sparta  Sta) 

02020007010 

3 

0 

02BA02 

02020007010020 

Wallkill  R  (Ogdensburg  to  SpartaStation) 

02020007010 

4 

0 

02BA03 

02020007010030 

Franklin  Pond  Creek 

02020007010 

5 

0 

02BA04 

02020007010040 

Wallkill  R  (Hamburg  SW  Bdy  to  Ogdensburg) 

02020007010 

6 

0 

02BA05 

02020007010050 

Hardistonville  tribs 

02020007010 

tdsWaterRegion  (n  = 

6  for  New  Jersey) 

WaterRegion_ID 

WaterRegionCode 

WaterRegion 

0 

— 

Unknown 

1 

1 

Passaic 

2 

2 

Raritan 

3 

3 

Atlantic  Coastal 

4 

4 

Upper  Delaware 

5 

5 

Lower  Delaware 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Location  Domains — Continued 


tdsWaterMgmntArea  (n  =  2 1  for  New  Jersey) 


WaterMgmntArea_ID 

WaterRegion_ID 

WaterMgmntAreaCode 

WaterMgmntArea 

0 

0 

- 

Unknown 

1 

4 

1 

Upper  Delaware 

2 

4 

2 

Walkill,  Pochuck,  and  Papakating 

3 

1 

3 

Pompton,  Pequannock,  Wanaque,  and  Ramapo 

4 

1 

4 

Lower  Passaic  and  Saddle 

5 

1 

5 

Hackensack  and  Pascack 

6 

1 

6 

Upper  Passaic.  Whippany,  and  Rockaway 

7 

2 

7 

Elizabeth,  Rahway,  and  Woodbridge 

8 

2 

8 

North  and  Sourth  Branch  Raritan 

9 

2 

9 

Lower  Raritan,  South,  and  Lawrence 

10 

2 

10 

Millstone 

11 

4 

11 

Central  Delaware 

12 

3 

12 

Monmouth  County 

13 

3 

13 

Barnegat  Bay 

14 

3 

14 

Mullica  and  Wading 

15 

3 

15 

Great  Egg  Harbor  and  Tuckahoe 

16 

3 

16 

Cape  May  County 

17 

5 

17 

Maruice,  Salem,  and  Cohansey 

18 

5 

18 

Lower  Delaware 

19 

5 

19 

Rancocas 

20 

5 

20 

Crosswicks 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Resource  Domains 


tdsResourceType  (n  =  7) 


ResourceType_ID 

GWorSW 

Salinity 

ResourceType 

0 

- 

- 

Unknown 

1 

GW 

FR 

Ground  water,  fresh 

2 

GW 

BR 

Ground-water,  brackish 

3 

GW 

SA 

Ground-water,  saline 

4 

SW 

FR 

Surface-water,  fresh 

5 

SW 

BR 

Surface-water,  brackish 

6 

SW 

SA 

Surface-water,  saline 

tdsWaterBodyType  (n  = 

14) 

WaterB  odyType_ID 

ResourceType_ID 

WaterB  odyType 

0 

0 

Unknown 

1 

4 

River/Stream 

2 

4 

Lake/Pond  -  surface  water 

3 

4 

Reservoir 

4 

1 

Spring 

5 

1 

Aquifer  -  freshwater 

6 

5 

Estuary  -  brackish 

7 

6 

Estuary  -  saline 

8 

6 

Bay 

9 

6 

Ocean 

10 

1 

Pond  -  ground  water 

11 

4 

Canal 

12 

4 

Surface  water  -  undefined 

13 

2 

Aquifer  -  brackish 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Resource  Domains — Continued 


tdsCriticalArea  (n  = 

4) 

CriticalArea_ID 

Critical  AreaCode 

CriticalArea 

0 

0 

Unknown 

1 

1 

Critical  Area  designated  in  the  northeast  Coastal  Plain  of  New  Jersey 

2 

2 

Critical  Area  designated  in  the  Camden  area  of  New  Jersey 

9 

9 

Not  Annlicable 

tdsCriticalZone  (n 

=  7) 

CriticalZone_ID 

CriticalZoneCode 

CriticalZone 

0 

0 

Unknown 

1 

1 

Well  is  in  the  depleted  zone  of  a  regulated  aquifer 

2 

2 

Well  is  in  the  threatened  margin  of  a  regulated  aquifer 

3 

3 

Well  is  within  the  composited  area  of  a  critical  area  but  does  not  tap  a 
regulated  aquifer 

4 

4 

Well  is  not  located  in  a  critical  area 

5 

5 

Well  taps  the  depleted  zone  or  threatened  margin  of  a  regulated 
aquifer  but  produces  less  than  3.1  million  gallons  per  month 

9 

9 

Not  Applicable 

tdxResourceDetailLabel  (currently  n  =  5) 


ResourceDetailLabel_ID 

ResourceDetailLabel 

ResourceDetailLabelMemo 

1 

Tributary  to 

2 

Surface  area-acres 

3 

Dam  name 

4 

August  median  flow 

5 

Fishery 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Miscellaneous  Domains 


tdsTimelnterval  (n  =  11) 


TimeInterval_ID 

Timelnterval 

1 

5 -year  period 

2 

Year 

3 

Season 

4 

Month 

5 

Week 

6 

Day 

7 

Multi-day 

8 

Indeterminate 

9 

Hour 

10 

Minute 

11 

Second 

tdsAddress  Type  (n 

=  3) 

AddressType_ID 

AddressType 

1 

Street  &  Mailing 

2 

Street 

3 

Mailing 

tdsOwnerType  (n  = 

V) 

OwnerType_ID 

OwnerType 

OwnerTypeMemo 

0 

Unknown 

Unknown  Owner  Type 

1 

None 

No  actual  owner 

2 

Private 

Privately  owned 

3 

Municipal 

Owned/operated  by  the  Municipal  government 

4 

County 

Owned/operated  by  the  County  government 

5 

State 

Owned/operated  by  the  State  government 

6 

Federal 

Owned/operated  by  the  Federal  government 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Miscellaneous  Domains — Continued 


tdxDataSource  (examples) 


DataSource_ID 

Owner_ID 

DataSource 

DataSourceMemo 

0 

0 

Unknown 

Data  Source  is  not  known 

1 

2 

BWA 

Bureau  of  Water  Allocation 

2 

3 

SDWIS 

Safe  Drinking  Water  Information  System 

3 

2 

NJGS  revised  BWA  files 

NJGS  revised  BWA  files 

4 

2 

NJPDES 

New  Jersey  Pollutant  Discharge  Elimination 

System  database 

tdxPermitLabel  (examples) 

PermitLabel_ID 

DataSource_ID 

PermitLabel 

PermitLabelMemo 

1 

1 

BWA 

2 

1 

Domestic  Wells 

3 

1 

DW  Service  Area 

4 

4 

NJPDES 
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Appendix  2.  NJWaTr  Domain  Table  Listings  by  Subject  Area — Continued 

Miscellaneous  Domains — Continued 


tdsPermitSeries  (n  =  11) 

PermitSeries_ID 

0 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 


PermitSeries 

Unknown 

10000W  registrations 
2000P  and  2000E  permits 
4000PS  permits 
5000  permits 
Agricultural  certifications 
Agricultural  registrations 
1000D  Dewatering  permits 
Domestic  Well  permits 
DW  Service  Area  permits 
NJPDES 


PermitSeriesDescription 

Unknown  Series 

Surface-  and  ground-water  withdrawals  at  a  rate  less  than  or  equal  to  100,000  gallons  per  day 
Surface-  and  ground-water  withdrawals  for  industrial,  golf-course,  and  institutional  use 
Surface-water  withdrawals  for  industrial  and  public  supply 
Surface-  and  ground-water  withdrawals  for  public  supplies 
Surface-  and  ground-water  withdrawals  for  agricultural  use 

Surface-  and  ground-water  withdrawals  for  agricultural  use  at  a  rate  less  than  or  equal  to  100,000  gallons  per  day 

Temporary  surface-  or  ground-water  withdrawals  required  for  a  construction  project 

Aggregated  and  estimated  ground-water  withdrawals  from  domestic  wells 

Water  distribution  systems  identified  by  one  PWS  ID 

New  Jersey  Permit  Discharge  Elimination  System  permit 


tdxAliasLabel  (example) 


AliasLabel_ID 

DataSource_ID 

AliasSource 

AliasLabel 

AliasLabelMemo 

1 

6 

Dept.  Civil  Engineering 

Rutgers  Station  ID 

Appendix  3.  Comparison  of  the  NJWaTr  and  NEWUDS  Data  Models 
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Appendix  3.  Comparison  of  the  NJWaTr  and  NEWUDS  Data 
Models 


The  differences  between  the  NJWaTr  data  model  and  the  original  NEWUDS  data  model  arc 
described  here.  Some  tables  and  fields  were  renamed,  redefined,  dropped  from,  or  added  to 
NEWUDS  to  create  NJWaTr.  Details  of  the  differences  arc  presented  below  by  subject  area  along 
with  a  summary. 

In  addition  to  the  items  listed  below,  two  general  changes  to  the  NEWUDS  design  have  been 
implemented  for  NJWaTr;  both  are  described  in  the  “Operational  Issues  and  Procedures”  section 
of  this  report.  (1)  All  non-associative  tables  are  equipped  in  NJWaTr  with  a  unique  index 
involving  one  or  more  non-PK  fields,  whereas  NEWUDS  had  only  the  mandatory  indexes  for  PK 
and  FK  fields.  (2)  The  maintenance  queries  arc  prefixed  with  the  letters  qrm  in  NJWaTr  rather 
than  the  qry  prefix  used  in  NEWUDS.  The  names  of  some  maintenance  queries  and  views  also 
were  adjusted  to  reflect  the  renaming  of  tables  or  fields  indicated  below. 


Site  Subject  Area 

Use  Classification 


•  The  USGS  and  New  England  use-classification  terms  in  the  nested  domains 
tdsUSGSUseType  and  tdsNEUseType  were  dropped. 

•  Two  new  use-classification  nested  domains  using  classification  terms  provided  by  NJDEP 
were  added— tds  Use  Group  and  tdsUseType. 

•  The  tdsSIC  and  tdsNAICS  industrial-classification  domains  and  their  relationships  to 
tblSite  were  dropped. 

•  The  table  tadUseConsumedF faction  used  optionally  to  store  estimated  monthly 
consumptive  use  percentages  for  different  UseTypes  was  added.  The  table  pairs  a 
UseType  with  a  Month  (integer  equivalent,  where  January  =  1  and  December  =  12)  and 
stores  the  fraction  of  water  available  that  is  assumed  to  be  consumed  during  that  month  of 
the  year  for  Sites  of  that  type. 

•  The  table  tcidSiteUseType  used  optionally  to  allow  Sites  with  a  primary  UseType  to  be 
further  identified  as  having  secondary  uses  was  added.  The  table  pairs  a  Site  with  a 
UseType  and  the  fractional  estimate  of  that  UseType  in  the  overall  classification  of  the 
Site. 

Site  Details 


•  The  tasSiteTypeDetailLabel  association  table  that  pairs  records  in  tdsSiteType  and 

tdxSiteDetailLabel  was  added  to  establish  data-driven  business  rules  that  identify  which 
labels  arc  appropriate  for  which  site  types.  The  table  can  be  used  within  a  query  or 
application  interface  to  determine  whether  Sites  of  certain  SiteTypes  have  the  appropriate 
detail  information  stored  in  the  database. 
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Site  Permits 


•  NEWUDS  used  the  Alias  entity  for  all  forms  of  alternative  identifiers,  including  Permits, 
whereas  the  Permits  arc  handled  separately  in  NJWaTr  to  allow  each  to  be  associated  with 
a  Permit  Series.  Permits  for  Sites  arc  handled  through  a  new  association  table 
tasSitePerm.it  that  pairs  Sites  with  Permit  records  in  the  new  tblPermit  table.  (See  below.) 


Conveyance  Subject  Area 

Expected  Transfer  Amount 

•  The  tadConveyanceExpectedFraction  table  was  added  to  handle  the  time-bounded 

estimate  of  the  proportion  in  the  From  Site  of  total  deliverable  quantity  expected  to  arrive 
at  the  Conveyance’s  To  Site.  Time-bounding  allows  the  estimate  to  be  amended  whenever 
the  From  Site’s  Conveyances  or  expected  deliveries  change. 


Transfer/Volume  Subject  Area 

Name  Change 

•  All  terms  using  “Transaction”  in  the  original  NEWUDS  model  were  changed  to 
“Transfer”  to  better  match  the  purpose  of  the  NJDEP  data  model. 

•  All  terms  using  “Rate”  were  changed  to  “Volume”  because  of  the  NJDEP  decision  to  store 
quantity  instead  of  rate  (quantity/time)  transfer  values. 

Quantity  data  instead  of  Rate  data 

•  Transfer  data  arc  stored  as  quantities  (for  example,  million  gallons)  rather  than  rates  (such 
as  million  gallons  per  day). 

•  The  Time  component  of  the  NEWUDS  tdsRateUnit  domain  was  dropped,  leaving  the 
Decimal  and  Quantity  (formerly  Volume)  components  as  the  only  items  that  make  up  the 
clustered  tdxVolumeUnit  domain. 
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Location  Subject  Area 


tbILocation 


•  The  NJEasting  and  NJNorthing  fields  were  added  to  handle  the  NJ  State  Coordinate 
system. 

State  Basin 


•  The  State  Basin  domain  and  association  tables  were  dropped.  These  arc  not  needed  for 
New  Jersey  because  the  state  uses  standard  hydrologic  unit  codes  (HUCs)  to  designate 
watersheds. 

tdsState/Countv/MCD  Domain  values 

•  State,  County,  and  MCD  domains  were  changed  from  New  England  values  to 
accommodate  the  NJ  region  (NJ,  NY,  PA,  DE,  MD)  using  data  from  the  2000  U.S.  Census. 
Definitions  were  adjusted  to  reflect  the  NJWaTr  content. 

Associations  of  Location  with  State.  County,  MCD,  and  HUC 

•  In  NEWUDS  only  the  HUC  domain  had  a  tad  association  table  connection  to  tbILocation , 
whereas  the  State,  County,  and  MCD  domains  were  direct  FK  joins. 

•  The  tad  tables  pairing  a  Location  to  one  or  more  State,  County,  and  MCD 
(tadLocationState ,  tadLocationCounty,  and  tadLocationMCD,  respectively)  were  added. 

•  The  two  non-PK  fields  in  each  of  the  tad  tables  arc  Fraction  to  indicate  the  percentage  of 
the  Location  that  is  within  each  of  the  associated  areas  and  IsPrimary  to  consistently 
identify  and  retrieve  a  single  domain  selection  for  the  Location  if  more  than  one  is 
associated. 

Drought  Region 

•  New  Jersey  has  divided  the  State  into  drought  regions.  Each  municipality  belongs  to  only 
one  drought  region.  The  domain  table  tdsDroughtRegion  was  added  to  the  model;  it  is  a 
parent  table  to  the  tdsMCD  domain  to  provide  drought  region  information  for  each 
municipality  identified  for  a  Location. 

tdsHUC 


•  The  tdsHUC  domain  in  NEWUDS  was  only  for  8-digit  HUCs  in  New  England.  The 
NJWaTr  HUC  domain  includes  8-,  11-,  and  14-digit  HUCs  in  a  static  array  (no  nesting  of 
HUC  levels  using  separate  tables)  covering  the  State  of  New  Jersey.  Fields  were  renamed 
to  show  HUC  levels  ( HUCx ,  HUCxName). 

•  Definitions  were  adjusted  to  reflect  the  NJWaTr  content. 

•  The  domain  contains  933  14-digit  HUCs  for  NJ;  1 1-digit  HUCs  do  not  have  standard 
names. 
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Water  Region  and  Watershed  Management  Area 


•  Two  nested  spatial  areas  for  New  Jersey  arc  the  Water  Region  and  Watershed  Management 
Area  (see  Hoffman  and  Lieberman,  2000).  Because  each  domain  has  an  official  code  and 
a  name/description,  these  were  added  as  nested  tables  (parent  tdsWciterRegion  and  child 
tdsWaterMgmntArea)  and  related  to  the  tdsHUC  domain  so  that  each  14-digit  HUC  is 
associated  with  a  single  Management  Area  and  its  parent  Region. 


Resource  Subject  Area 

Critical  Area  and  Zone 


•  Two  domains,  tdsCriticalArea  and  tdsCriticalZone,  were  added  to  the  tcidSiteResource 
association  table  to  identify  diversion  sources  or  withdrawals  in  either  of  two  regulated 
aquifer  areas  defined  within  New  Jersey.  A  “not  applicable”  selection  can  be  assigned  to 
Sites  not  associated  with  these  spatial  areas. 

Resource  Owner 


•  An  Owner  was  added  to  each  Resource  by  adding  Owner _ID  as  a  mandatory,  non-PK 
foreign  key  in  the  tblResource  table.  A  “No  Owner”  selection  can  be  assigned  to  a 
Resource  that  does  not  have  a  designated  Owner. 

Resource  Details 


•  Storage  of  Resource  Details  was  set  in  tadResourceDetail  to  be  time-bounded  with  the 
addition  of  the  fields  ResourceDetailEJfectiveDate  and  ResourceDetailEndingDate. 

•  The  PK  of  the  tadResourceDetail  table  was  adjusted  to  include  the  three  fields, 
Resource_ID  +  ResourceDetailLabel_lD  +  ResourceDetadEjfectiveDate ,  to  allow 
multiple,  time-bounded  values  for  a  single  label. 

Resource  Structure 


•  The  association  table  tadResourceStructure  was  added  to  pair  two  records  at  a  time  from 
the  tblResource  table  to  show  the  component  Resources  for  a  composite  Resource,  along 
with  the  optional  fractional  amount  of  the  parent  represented  by  the  child,  and  a 
designation  of  a  primary  child  Resource  for  the  composite  parent. 

Water  Body  Type  and  Detail  Label  association 

•  The  table  tasWaterBodyDetailLabel  was  added  to  pair  records  from  WaterBodyType  and 
ResourceDetailLabel  in  order  to  establish  data-driven  business  rules  that  identify  which 
labels  arc  appropriate  for  different  waterbody  types.  The  table  can  be  used  within  a  query 
or  application  interface  to  determine  whether  Resources  of  certain  WaterBody Types  have 
the  appropriate  detail  information  stored  in  the  database. 
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Permit  Subject  Area 


Permits 


•  A  new  subject  area  focused  on  the  tblPermit  table  was  added  to  handle  Permits  assigned  to 
Sites  and  Owners.  Permit  numbers  were  identified  as  critical  to  associations  with  other 
data  sources  and  to  retrievals.  The  Permit  structure  is  similar  to  the  Alias  subject  area,  the 
latter  having  been  retained  in  the  NJWaTr  model  to  handle  all  non-Permit  alternative 
identification  schemes  for  Sites,  Conveyances,  and  Resources. 

•  The  Permit  structure  includes  the  new  domain  tdsPermitSeries  to  classify  each  Permit 
according  to  a  New  Jersey  scheme. 

•  Two  new  association  tables  join  tblSite  to  tblPermit  ( tasSitePermit )  and  tblOwner  to 
tblPermit  (tas Owner Permit)  to  associate  individual  Sites  and  Owners  with  individual 
Permits. 

•  Note  that  Permits  arc  not  assigned  directly  to  Resources.  Permits  associated  with 
Resources  are  gathered  through  the  relationship  between  an  individual  Resource  and  an 
individual  Site  or  Owner.  Resource  “allocations,”  if  assigned  directly  to  Resources,  are 
handled  through  the  tadResourceDetail  table. 


Summary  of  differences  between  NJWaTr  and  NEWUDS 

New  Tables  in  NJWaTr  (n  =  21)  listed  alphabetically 

•  tadConveyanceExpectedFraction 

•  tadLocationCounty 

•  tadLocationMCD 

•  tadLocationState 

•  tadResourceStructure 

•  tadSiteUseType 

•  tadUseConsumedFraction 

•  tasOwnerPermit 

•  tasSitePermit 

•  tasSiteTypeDetailLabel 

•  tasWaterBodyDetailLabel 

•  tblPermit 

•  tdsCriticalArea 

•  tdsCriticalZone 

•  tdsDroughtRegion 

•  tdsPermitSeries 

•  tdsUseGroup 

•  tdsUseType 

•  tdsWaterMgmntArea 

•  tdsWaterRegion 

•  tdxPermit Label 
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Dropped  Tables  from  NEWUDS  (n=7)  listed  alphabetically 


•  tadLocationStateBasin 

•  tdsNAICS 

•  tdsNEUseType 

•  tdsRateUnitTime 

•  tdsSIC 

•  tdsStateBasin 

•  tdsUSGSUseType 

Changes  to  Tables  that  existed  in  the  NEWUDS  model 

•  In  the  tblSite  table,  the  SIC  and  NAICS  domain  foreign  key  fields  were  dropped. 

•  In  the  tblSite  table,  the  foreign  key  NEUseType_ID  was  reset  to  the  new  domain 
UseType_ID  . 

•  All  Transaction  terms  were  renamed  Transfer. 

•  All  Rate  terms  were  renamed  Volume ,  and  the  resulting  VolumeUnitVolume  term  was 
renamed  VolumeU nitQuantity. 

•  In  the  tdxVolumeUnit  (formerly  tdxRateUnif)  table,  the  foreign  key  for  the  time 
component  ( RateUnitTime_ID )  was  dropped  as  a  result  of  the  switch  from  Rate  to  Volume 
storage. 

•  In  the  tblLocation  table,  NJNorthing  and  NJEasting  state  coordinate  fields  were  added. 

•  The  tdsHUC,  tdsState,  tdsCounty,  and  tdsMCD  tables  were  populated  with  New  Jersey 
and  surrounding  states’  items  and  codes. 

•  The  tdsElUC  table  was  expanded  for  8-,  11-,  and  14-digit  HUCS.  The  New  Jersey 
WatershedCode  was  added,  and  a  new  WaterMgmntArea_ID  foreign  key  from  the  new 
nested  tdsWaterMgmntArea  and  tdsWaterRegion  domains  was  added. 

•  In  the  tdsMCD  table,  a  foreign  key  was  added  from  the  new  tdsDroughtRegion  domain. 

•  The  tadSiteRe source  association  table  was  amended  to  include  foreign  keys  to  the  new 
domains  tdsCriticalArea  and  tds Critic alZone. 

•  The  tblResource  table  was  assigned  an  Owner  with  the  addition  of  a  foreign  key 
Owner_ID  field. 

•  The  tadResourceDetail  table  was  set  in  NJWaTr  for  time-bounding  of  detail  values  with 
the  addition  of  the  ResourceDetailEffectiveDate  and  ResourceDetailEndingDate  fields. 
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